Comments

B to Be

A pdf of the complete Praxis Comparative Glossary can be downloaded here.

 

From Backlog to Beta distribution

 

Backlog

A term frequently used in agile development for a list of prioritised product requirements or features. Prioritisation is typically done using techniques such as MoSCoW.

Each sprint or timebox plans to deliver a selection of products or features from the backlog.

Backward pass

More:

The second phase of critical path analysis. It calculates the latest starts and latest finishes of activities.

Balance

A phase in the APM BoK portfolio life cycle where the combined risk, resource usage, cash flow and impact on the business of the component projects and programmes is balanced.

Also an activity in the Praxis portfolio management process.

Balanced matrix

More:

A form of matrix organisation that gives equal authority to the project and functional sides of the matrix. There is a designated project manager but he or she is still within one of the functions. Although better for the project than the weak matrix, there is still the danger that the project manager has divided loyalties between the project and his or her functional manager.

Bar chart

See Gantt chart.

Base date

See progress date.

Baseline

A baseline is a measure of anything that may change, before it is changed.
For example:

A budget is a form of cost baseline.

Baseline cost

The amount of money an activity, project or part of a project was intended to cost when the schedule baseline was set.

Baseline duration

The duration that an activity, project or part of a project was intended to take when the schedule baseline was set.

Baseline effort

The effort assigned to an activity, project or part of a project when the schedule baseline was set.

Baseline finish date

The scheduled finish date of an activity, stage or milestone at the time the schedule baseline was set.

Baseline management product

In PRINCE2 this is a type of management product that, once approved, is subject to formal change control.

Baseline review

A review to establish whether the baseline being used is still valid for the purposes of monitoring progress on the project. If the scope of the project has changed significantly since the baseline was set, it may not be valid to compare current progress against the original baseline. It may be necessary to reset the project's baseline in order to exercise control.

Baseline schedule

When the plans are agreed and work is about to start on the project’s products, the project schedule and costs are baselined. These provide reference points against which progress can be compared as work proceeds.

During the project, reports are produced that compare actual progress against the baselined schedule. Typical examples are the financial comparisons produced during earned value management and an actual vs. baseline Gantt chart.

The GAO SAG also points out that this baseline should represent the “consensus of all stakeholders” with regard to the schedule.

Baseline start date

The scheduled start date of an activity, stage or milestone at the time the schedule baseline was set.

Basis document

A document from the GAO SAG that provides a narrative for the Integrated Master Schedule (IMS).

It describes the approach to logic, resources and calculation used in the IMS and is therefore very similar in scope to the schedule management plan in Praxis.

Basis of estimates

Documentation that explains and supports how estimates were constructed.

Belbin

More:

An often quoted system for categorising people’s roles within a team is that of R. Meredith Belbin who studied teams working on management games and experimented with different mixes of people.

His initial approach was to group the most able people together to form an elite team. These teams did not perform well and Belbin concluded that a high performing team needs a complementary mix of characters. He identified nine team types, each of which have positive contributions to make to a team but also have what Belbin terms ‘allowable weaknesses’.

Benefit

All projects and programmes must deliver some form of benefit to the host organisation otherwise there is no point in undertaking the work. Some benefits, such as cost savings through lower energy bills, are tangible and easily quantifiable. Others, such as increased staff morale are harder to quantify.

Change management must be used to derive tangible benefits from the outcomes. For example, increased staff morale may lead to lower staff turnover, which in turn could lead to a tangible and quantifiable saving from reduced recruitment costs.

The sum of the quantifiable benefits is what will justify the investment in the project as described in the business case.

Benefit owner

The benefits that are identified in a business case must have owners. Overall ownership of benefits resides with the sponsor.

Individual benefits will be owned by the person who is responsible for managing the change that delivers the benefit – often referred to as a business change manager.

Benefit profile

More:

A benefit profile is used to define both benefits and dis-benefits. It is typically developed during the definition process of a project or programme following requirements management. The profile includes sections that describe the benefit or dis-benefit and how it will be realised and measured.

Benefit realisation review

See benefits review.

Benefit/cost analysis

The analysis of the potential costs and benefits of a project to allow comparison of the returns from alternative forms of investment. Usually expressed as a simple ratio of the value of benefits to costs.

Sometimes referred to as cost/benefit analysis. The principle is exactly the same but the ratio is reversed.

Benefit/project matrix

There is rarely a one-to-one relationship between benefits and projects within a programme. It is more usually the case that a project will contribute towards more than one benefit and a benefit will be facilitated by more than one project.

A benefit/project matrix maps projects against benefits. It can be populated with the proportion of the value of each benefit that is attributable to each project. This helps with the development of business cases for each project.

Benefits log

See benefits register.

Benefits management

More:

This Praxis function defines benefits, implements the necessary change and ensures the benefits are realised. Its goals are to:

  • define benefits and dis-benefits of the proposed work;
  • establish measurement mechanisms;
  • implement any change needed in order to realise benefits;
  • measure improvement and compare to the business case.

Also a function in the APM BoK.

PRINCE2, ISO21500 and the PMBoK®* guide do not include the realisation of benefits but they make reference to it being performed after the project is complete, i.e. projects run using these three guides concludes when the output is delivered. In Praxis the realisation of benefits may be part of a project.

* It is intended to incorporate benefits management in the sixth edition of the PMBoK®

Benefits management (MSP theme)

This theme from MSP covers the same ground as the benefits management function in Praxis.

Benefits management plan

More:

A separate benefits management plan (as opposed to a benefits section in the scope management plan) will often be required where there are multiple benefits, significant change and the relationships between outputs and benefits are more complex, i.e. a benefits management plan is usually appropriate where the work is managed as a programme rather than a project.

Benefits map

More

A benefits map is a form of influence diagram and is needed where there are complex relationships between multiple outputs, benefits and the strategic objectives that the benefits support. Within these relationships there may be dis-benefits, and outcomes that form a bridge between outputs and benefits.

Benefits realisation plan

A document in MSP and the SPgM that shows the timing of benefits realisation activities.

Benefits realisation process

More:

This Praxis process manages the realisation of benefits for both projects and programmes.

It is usually the case that simply producing an output does not automatically realise benefits. In most cases an output is used to change some aspect of an organisation’s mode of operation or environment. Implicit within the word ‘change’ is a quantifiable improvement in one or more performance indicators to which value has been assigned.

The goals of this process are to:

  • establish the current state of what is being changed;
  • co-ordinate the delivery of outputs with the management of change;
  • ensure changes are permanent;
  • establish whether benefits have been achieved.

In its simplest form, realising benefits is about measuring current performance, helping the people who make up the organisation through the period of change (the transition) and finally, measuring the improvement in performance.

PRINCE2, ISO21500 and the PMBoK® guide do not include the realisation of benefits but they make reference to it being performed after the project is complete, i.e. projects run using these three guides concludes when the output is delivered. In Praxis the realisation of benefits may be part of a project.

Benefits register

A list of the benefits arising from a project or programme with key data about each benefit. This acts as an index of benefit profiles.

Benefits review

Benefits are realised over a period of time. This will be monitored on a day-to-day basis but periodically a formal benefits review should be conducted. This will involve a review of change management and benefits management procedures as well as comparison of actual benefits realised against the planned benefits.

Benefits review plan

A PRINCE2 project does not include benefits realisation. It is assumed that this will be performed by a host programme or business as usual. However, the project does have responsibility for planning benefits reviews and this is set out in the benefits review plan.

Benefits Sustainment

The SPgM term for ongoing activities that continue after the demobilisation of the program organisation to ensure that benefits are realised.

Benefits tolerance

Tolerance as applied to a benefit.

PRINCE2 requires this to be documented in the business case.

Berlo

More:

David Berlo1 set out his theory of communication in 1960. It is also known as the SMCR model because of its four components: source, message, channel and receiver.

 

  1. Berlo, D., (1960), The process of communication: an introduction to theory and practice, Holt, Reinhart and Winston, New York.

Best practice

A term widely used in guides and standards to describe their content. The term is generally accepted as being shorthand for ‘best current practice’, i.e. if practices were literally ‘best’ they could not be improved.

All ‘best practice’ evolves and (hopefully) gets better. This term should therefore be taken as the current view of best practice.

Beta distribution

More:

A statistical distribution that is commonly used in PERT analysis and Monte Carlo analysis.

 

SHARE THIS PAGE

14.Feb.2017Updated to version 1.3 including the PMI's standard for program management

B to Be

Back to top