Project Business Documents

The project manager needs to ensure that the project management approach captures the intent of business documents. These documents are defined in Table 1-5.

The PMBoK Guide says:

“These two documents are interdependent and iteratively developed and maintained throughout the life cycle of the project. The project sponsor is generally accountable for the development and maintenance of the project business case document. The project manager is responsible for providing recommendations and oversight to keep the project business case, project management plan, project charter, and project benefits management plan success measures in alignment with one another and with the goals and objectives of the organization. Project managers should appropriately tailor the noted project management documents for their projects.” Now stop for a moment! You almost certainly misunderstood what I just said -- almost everyone does -- and that misunderstanding can cost you 1 or 2 questions in the exam. We are talking about Project Business Documents” -- Right?

The PMBoK Guide says:

“Project Managers should appropriately tailor the noted project management documents for their projects.” Read it carefully. The PMBoK Guide is NOT saying “Project Managers should appropriately tailor the noted project BUSINESS documents for their projects”. The paragraph started talking about project BUSINESS documents, but in this sentence, it is talking about Project MANAGEMENT Documents, not project BUSINESS documents. The Project Manager USES the two Project Business Documents -- the business case and the benefits management plan --but is not authorized to change them. But on a project, there are also 33 Project Management Documents (or just called Project Documents), and the Project Manager will change these. The paragraph tells us that the Project Manager can recommend changes to them, but they are maintained by the Sponsor. 

Figure 1-8 illustrates the interrelationship of these critical business documents and the needs assessment as well as an approximation of the life cycle of these various documents against the generic life cycle.

PROJECT BUSINESS CASE 

A business case provides a justification for a project along with associated risks, situational analysis,  solution options and recommendations. Related assumptions and constraints are also stated.

A benefits management plan on the other hand documents how and when benefits will be delivered by the project (usually many will be delivered after the project is completed). Owners and measures will also be documented apart from risks and assumptions.

The PMBoK Guide says:

“The project business case is a documented economic feasibility study used to establish the validity of the benefits of a selected component lacking sufficient definition and that is used as a basis for the authorization of further project management activities.” The business case lists the objectives and reasons for project initiation. It helps measure the project success at the end of the project against the project objectives. The business case is a project business document that is used throughout the project lifecycle. The business case may be used before the project initiation and may result in a go/no-go decision for the project. A needs assessment often precedes the business case. The needs assessment involves understanding business goals and objectives, issues, and opportunities and recommending proposals to address them. The results of the needs assessment may be summarized in the business case document. The process of defining the business need, analysing the situation, making recommendations, and defining evaluation criteria is applicable to any organization’s projects.

A business case may include documenting the following: 

And in the exam, you may be asked a question on the following headings or the subheadings.

Business needs:

• Determination of what is prompting the need for action; why are we doing this? Do we need to fix something, or do we want to increase sales, or comply with legislation, for example?

• A situational statement documenting the business problem or opportunity to be addressed including the value to be delivered to the organization; What is the specific problem, opportunity or mandate that is driving this?

• Identification of stakeholders affected; and

• Identification of the scope. This is not the scope statement initially. It is just the main deliverables, but this will be progressively elaborated during the project.

Analysis of the situation:

So far we have said that perhaps we can see an opportunity to increase sales, by developing a better type of mousetrap. We have listed the main affected stakeholders. Please note that mice are not considered stakeholders, even though they will be affected by the project.

Now we need to properly analyse the situation, rather than just rushing ahead.

The analysis might include:

• Identification of organizational strategies, goals, and objectives;

• Identification of root cause(s) of the problem or main contributors of an opportunity;

• Gap analysis of capabilities needed for the project versus existing capabilities of the organization;

• Identification of known risks;

• Identification of critical success factors;

• Identification of decision criteria by which the various courses of action may be assessed; 

Examples of criteria categories used for analysis of a situation are:

• Required: This is a criterion that must be fulfilled. E.g. the mousetrap must be able to kill mice swiftly, without suffering.

• Desired: This is a criterion that we would really like to have fulfilled, but it is not essential. E.g. we would prefer it if the trap did not require food as bait.

• Optional: This is a criterion that is not essential. Fulfilment of this criterion may become a differentiator between alternative courses of action. E.g. the mousetrap won’t harm white mice because we don’t want pet mice to get armed.

Identification of a set of options to be considered for addressing the business problem or opportunity.

The commonly used 3 options are:

• Do nothing.This is also referred to as the “business as usual” option. Selection of this option results in the project not being authorized.

• Do the minimum work possible to address the problem or opportunity.The minimum may be established by identifying the set of documented criteria that are key to addressing the problem or opportunity.

• Do more than the minimum work possible to address the problem or opportunity.This option meets the minimum set of criteria and some or all of the other documented criteria.There may be more than one of these options documented in the business case.

Recommendation:

We have considered the reasons for starting a project. We have analysed the situation in detail and we have considered options. Now is the time to pull all this information together, and recommend what the organization should do.

A statement of the recommended option to pursue in the project;

E.g. we will develop an electric mousetrap, which has Artificial Intelligence and Machine Learning capabilities, so it can constantly evolve to become an even better mousetrap.

Items to include in the statement may include:

•  Analysis results for the potential option;

•  Constraints, assumptions, risks, and dependencies for the potential options; and

•  Success measures 

An implementation approach that may include:

• Milestones,

• Dependencies, and

• Roles and responsibilities.

Evaluation: 

A statement describing the plan for measuring benefits the project will deliver.

This will cover not just the benefits realized -- if any --during the project. For example, during testing, the project will reduce the number of mice in the organization. But we also want to look at benefits when the product has been moved into Operations.

The business case document provides the basis to measure success and progress throughout the project lifecycle by comparing the results with the objectives and the identified success criteria.

PROJECT BENEFITS MANAGEMENT PLAN 

The project benefits management plan is the document that describes how and when the benefits of the project will be delivered and describe the mechanisms that should be in place to measure those benefits. For example, if the project is intended to enable the Service Desk to solve customer problems 20% faster on average; what does this actually mean, and how can it be measured? 

The PMBoK Guide says:

A project benefit is defined as an outcome of actions, behaviours, products, services, or results that provide value to the sponsoring organization as well as to the project’s intended beneficiaries.
Development of the benefits management plan begins early in the project lifecycle with the definition of the target benefits to be realized.

The benefits management plan describes key elements of the benefits and may include documenting the following: 

• Target benefits (e.g., the expected tangible and intangible value to be gained by the implementation of the project; financial value is expressed as net present value); 

• Strategic alignment (e.g., how well the project benefits align with the business strategies of the organization); 

• The timeframe for realizing benefits (e.g., benefits by phase, short-term, long-term, and ongoing); 

• Benefits owner (e.g., the accountable person to monitor, record, and report realized benefits throughout the timeframe established in the plan); 

• Metrics (e.g., the measures to be used to show the benefits realized, direct measures, and indirect measures);  This is a very important one. Benefits must be measurable, because if you can’t measure them, how can you tell if the project was a success. In the example for the Service Desk, I said that customer problem was to be solved 20% faster on average. But if I had just said, “The Service Desk to solve customer problems faster”, you can’t measure that and so you can’t tell if you achieved it.

• Assumptions (e.g., factors expected to be in place or to be in evidence); and 

• Risks (e.g., risks for a realization of benefits).

Developing the benefits management plan makes use of the data and information documented in the business case and needs assessment.

For example, the cost-benefit analyses recorded in the documents illustrate the estimate of costs compared to the value of the benefits realized by the project.

The benefits management plan and the project management plan include a description of how the business value resulting from the project becomes part of the organization’s ongoing operations, including the metrics to be used.
The metrics provide verification of the business value and validation of the project’s success.

PROJECT CHARTER and PROJECT MANAGEMENT PLAN 

For the exam, please remember: 

• The project charter is defined as a document issued by the project sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

• The project management plan is defined as the document that describes how the project will be executed, monitored, and controlled.

• There are 33 project documents in a project, which are used to manage the project, but they are not part of the project management plan.

PROJECT SUCCESS MEASURES 

Please read PROJECT SUCCESS MEASURES in the PMBoK Guide, page 34. It is quite a simple section to understand; in fact, it’s mainly a list.

That brings us to the end of Project Management business documents and also to the end of the Foundational Elements module. At the start of this module, I promised that you learned important information from it, and I have no doubt that you have.

The next module is “2.0 Environments in which projects operate ”. Please read the corresponding chapter in the PMBoK Guide before watching the video. So that you can operate well in the examination environment.