D to Del

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

 

From Daily log to Delphi technique

 

Daily log

More:

A daily log is a personal document that records informal information that is not stored in any of the other defined documentation. It is primarily a diary of events that its owner can use as an aide memoire of conversations and decisions.

This document is used in both Praxis and PRINCE2.

Daily scrum

The Scrum 2020 term for a daily stand-up

Daily stand-up

A short meeting to assess progress, typically occurring daily and limited to 15 minutes. The meeting discusses what has been done the previous day, will be done today and any problems being encountered.

Usually associated with the scrum approach to product development.

Dangle

Most network diagrams are drawn with a single start activity and a single finish activity. If other activities have either no predecessors or no successors they are referred to as dangles.

Dangling logic

The GAO SAG term for a dangle.

Dashboard report

A concise report showing (usually in graphical form) the key performance indicators for a project, programme or portfolio.

Data date

The PMBoK® guide term for the progress date.

Date constraint

The GAO SAG term for imposed dates.

Decision bias

Projects and programmes constantly require decisions to be made. These decisions may be affected by various cognitive biases. For example: ‘confirmation bias’ is the tendency to interpret information in a way that is consistent with existing personal beliefs and ‘anchoring bias’ is where people tend to overly rely on one specific piece of information.

Decision gate

The preferred APM BoK 7 term for a gate.

Decision networks

See probabilistic networks.

Decision point

A generic term used by MSP 5th Ed. to indicate an event or occurrence that triggers the need for programme governance to make decisions about the future of the programme.

Decision quality

A concept from MSP 5th Ed. intended to support organisations in making appropriate decisions by focusing on the decision making process. Achieving good quality decisions is described by the decisions theme (although the term ‘decision quality’ doesn’t actually appear in that chapter).

Decision register

An MSP 5th Ed. document that provides an audit trail of decisions made by each governance board.

Decision trees

More:

A decision tree is a technique for identifying alternative courses of action and their implications (often in terms of cost). It shows decisions and consequences as lines between nodes. If the object is to quantify costs, the expected cost of decisions and their possible outcomes can be calculated for any node in the tree. The purpose is to calculate the full implications of a decision rather than just the initial cost.

Decisions (MSP 5th Ed. theme)

Decision making is ubiquitous in projects and programmes. MSP 5th Ed. extract this out into a discrete theme that describes how decisions are made at various points in the life cycle and discusses the pre-requisites for effective decision making.

Decomposition

The process of dividing elements of a breakdown structure into smaller components.

Define

The part of the portfolio life cycle where the projects, programmes and (if appropriate) change to business as usual are defined.

In Praxis, this phase is managed as part of the portfolio management process.

Define activities (4.3.13)

The third process within ISO21500’s scope subject group.

It is a planning process that uses the work breakdown structure to identify the work needed to produce the project’s products. The output is an activity list.

In Praxis the equivalent is the identify work step in the schedule management function.

The PRINCE2 equivalent is the first part of the identifying activities and dependencies step in the plans theme, which follows on from the development of a product flow diagram.

The PMBoK® guide categorises this work as part of the Project Time Management knowledge area using the Define Activities process.

Define Activities (6.2)

The second process within the PMBoK® guide’s Project Time Management knowledge area.

It is a planning process that uses the scope baseline to identify the work needed to produce the project’s products. The outputs are an activity list, activity attributes and a milestone list.

In Praxis the equivalent is the identify work step in the schedule management function.
The PRINCE2 equivalent is the first part of the identifying activities and dependencies step in the plans theme, which follows on from the development of a product flow diagram.

ISO21500 categorises this work as part of the scope subject group using the process Define activities

Define project organisation (4.3.17)

This ISO21500 process defines the full project organisation with roles and responsibilities.

In the PMBoK® guide this is covered by Plan Human Resource Management.
Praxis and PRINCE2 make the distinction between the management team and the delivery team. When describing organisational activities they both focus on the management team.

In Praxis appointments are covered in appoint identification team in the identification process and appoint definition team in the definition process.

Similarly, PRINCE2 has the organisation theme and the design and appoint the project management team activity in the Starting Up a Project (SU) process.

Define scope (4.3.11)

An ISO21500 process that develops a detailed description of the project and its products. The equivalent in the PMBoK® guide is Define Scope.

The equivalent in Praxis is the define scope activity in the definition process. In PRINCE2 it is the create the project plan activity in the Initiating a Project (IP) process (which includes the preparation of all product descriptions).

Define Scope (5.3)

A PMBoK® guide process that develops a detailed description of the project and its products. The equivalent in ISO21500 is Define scope.

The equivalent in Praxis is the define scope activity in the definition process. In PRINCE2 it is the create the project plan activity in the Initiating a Project (IP) process (which includes the preparation of all product descriptions).

Defining a Programme

This is the second process in the MSP transformational flow. Its objectives are to undertake detailed definition and planning so that a decision can be made whether or not to proceed with the programme.

The process starts with the programme brief and key outputs include a detailed business case, programme structure and governance baselines.

It is the programme equivalent of Initiating a Project in PRINCE2 and as these processes are so similar, Praxis brings them together into the single Definition process.

The equivalent in SPgM it is a combination of elements from the 13 Program Definition processes (Note: the Program Definition phase in the SPgM is a combination of the identification and definition processes in MSP)

Definition

The second phase of a project or programme life cycle where requirements are refined, a preferred solution identified and plans prepared.

In Praxis this phase is managed by the definition process, in PRINCE2 by the Initiating a Project (IP) process, in the PMBoK® guide by the Develop Project Management Plan process and in ISO21500 by the Develop project plans process.

In programmes, MSP manages this phase in Defining a Programme and in SPgM it is a combination of elements from the 13 Program Definition processes (Note: the Program Definition phase in the SPgM is a combination of the identification and definition phases in Praxis)

Definition documentation

At the end of the Praxis definition process, a request for authorisation will be submitted to the project or programme sponsor. The decision whether or not to proceed to the delivery phase will be made after a review of the relevant definition documentation which typically includes:

This is broadly equivalent to the PRINCE2 project initiation documentation and the project management plan in the PMBoK® guide and ISO21500.

Definition of done

A term used in agile for acceptance criteria. In Scrum 2020 the definition of done specifically relates to the completion of an increment.

Definition of ready

An agile term for the criteria that must be in place for a piece of work (activity, work package, stage etc.) to be started.

Similar to the planning term ‘make ready needs’.

Definition plan

The definition plan is created in the identification process and, alongside the brief, is one of the documents submitted to the sponsor when seeking approval for the definition phase of the life cycle.

This document is based on the general delivery plan format and adapted to suit the context of the work. Since this plan only exists in conjunction with a project or programme brief, its content can be simplified to avoid duplication.

Definition process

More:

This process manages the definition phase of the project or programme life cycle. Its goals are to:

  • develop a detailed picture of the project or programme;
  • determine whether the work is justified;
  • describe governance policies that describe how the work will be managed;
  • gain the sponsor’s authorisation for the delivery phase.

An authorised brief and definition plan will trigger the process, which is fundamentally the same regardless of whether it has been decided to govern the work as a project or a programme. The output will be a set of documents that describe all aspects of the work, with their content and detail varying to suit the context.

This is equivalent to the Initiating a Project (IP) process in PRINCE2, the Develop project plans process in ISO21500 and the Develop Project Management Plan process in the PMBoK® guide.

For programme management the equivalent process in MSP is Defining a Programme and in SPgM it is a combination of elements from the 13 Program Definition processes (Note: the Program Definition phase in the SPgM is a combination of the identification and definition phases in Praxis)

Definition team

The team that manages the definition process in Praxis.

On smaller projects the same team will manage the work through its entire life cycle. On more complex projects and programmes the management team may change in its make up between the identification, definition and deliver phases of the life cycle.

See also: identification team.

Definitive estimate

An estimate resulting from bottom-up estimating. Sources vary, but a definitive estimate is normally considered to be within ± 5-10%.

Delegated limits of authority

Limits of decision making authority and accountability for different roles in an organisation. For example, in terms of expenditure that can be approved.

Delegation

More:

Delegation is the practice of giving a person or group the authority and responsibility to perform specific activities on behalf of another. The act of delegation does not transfer accountability and the person who has delegated the work remains accountable for its results.

The goals of delegation are to:

  • allocate work effectively to individuals teams and suppliers within the project, programme or portfolio;
  • use delegation as a motivation and development tool.

The APM BoK also contains a delegation function.

While PRINCE2 doesn’t describe the tools and techniques of delegation it does go into some detail about how delegation is applied in the organisation structure. This is included in the progress theme.

The PMBoK® guide and ISO21500 do not discuss delegation.

Deliberate decision event

An event in a probabilistic network where a decision is made based upon the outcome of the preceding activities or any other information that prevents the decision being made automatically. In other words, finalising the sequence of activities will need human intervention when the necessary information is available.

Deliver the capabilities (MSP 5th Ed.)

The purpose of this MSP 5th Ed. process is to “oversee programme delivery”. In this respect it is broadly equivalent to the Delivering the capability and Manging the Tranches processes in the 4th Ed.

The equivalent in Praxis is the application of the delivery and development processes in a programme environment.

Deliver a Work Package

An activity from the PRINCE2 Managing Product Delivery (MP) process.
This is where the individual or team that has created a work package hands it over to the project manager. The activity includes quality checks and updates to relevant plans.

The equivalent in Praxis is the deliver products activity in the development process.

The PMBoK® guide does not formally define the project manager/product development team relationship but, in general, the delivery of products is covered by the Direct and Manage Project Work process.

ISO21500 does not have products or deliverables as a primary output of any of its processes. Instead it explains, in Direct project work, that “deliverables are the result of the integrated processes performed as defined in the project plans.”

Deliverable

A product that is to be delivered to the user/customer.

Delivering the Capability (MSP 4th Ed.)

This is a process from the MSP transformational flow. It covers the coordination and management of project delivery according to the programme plan in order to achieve the blueprint.

This process must work closely with the Realizing the Benefits process to ensure that project outputs successfully create benefits.

Praxis combines the process models for projects and programmes and its equivalent is the delivery process.

MSP 5th Ed. addresses this in the process Deliver the capabilities.

Delivery

More:

This is an area in Praxis that is about the functions immediately concerned with the delivery of outputs, outcomes and benefits. Six of the sections deal with components that are fundamental to every project, programme and portfolio:

Delivery documents

Praxis defined three categories of documentation. Delivery documents are the most dynamic of the three documentation groups and should be maintained in accordance with the principles of information management and configuration management.

They are at the heart of executing the work and are primarily used in the delivery, development and boundaries processes.

Delivery plan

Praxis uses the term delivery plan to distinguish a document from a management plan.

Delivery plans come in various shapes and sizes. The first delivery plan to be prepared will be the project or programme definition plan. Subsequently, delivery plans can be prepared to cover a part of the life cycle (e.g. a stage or tranche plan), a delivery component (e.g. a benefits review plan or communication plan) or a specialist plan (e.g. an exception plan or contingency plan).

It is useful for all types of delivery plan to follow a consistent format although this should be adapted as necessary and not followed slavishly.

Delivery process

More:

This Praxis process manages the delivery phase of the project or programme life cycle.

The delivery phase of a small project may comprise only one stage; the delivery phase of a programme may comprise only one tranche. Most projects and programmes will comprise multiple stages or tranches that are conducted in serial or parallel.

The goals of delivering a project or programme are then to:

  • delegate responsibility for producing deliverables to the appropriate people;
  • monitor the performance of the work and track against the delivery plans;
  • take action where necessary to keep work in line with plans;
  • escalate issues and replan if necessary;
  • accept work as it is completed;
  • maintain communications with all stakeholders.

This is equivalent to the Controlling a Stage (CS) process in PRINCE2.
In the PMBoK® guide there are three processes that together cover the same area:

Similarly, in ISO21500 this area is covered by:

For programme management the equivalent process in MSP is Delivering the Capability and in SPgM it is a combination of elements from the Program Delivery Management and Program Performance Monitoring and Control processes.

Delivery team

Praxis makes a distinction between the management team and the delivery team. The delivery team includes all those who are responsible for performing the activities that deliver products. This may include internal resources and external resources (suppliers).

Delphi technique

More:

The Delphi technique is an iterative process for gaining consensus on an issue from a group of subject matter experts. It has been used very effectively by large organisations for strategic business planning.

 

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top