1.    INTRODUCTION

Project Owners often think of project initiation as the time when they have determined the project mandate and objectives, and started to assemble a project team who will begin the work. Long before assembling the project team, however, project Owners must assess the requirements and value of the project or risk succumbing to the most common root cause of project failure. Before the project team is assembled, it is essential that project Owners understand the business value that is being sought and what alternatives are available to deliver this value. If a project is a leading opportunity, then exactly what does the project need to deliver to produce the business value? This should then be expressed in terms of business and project goals that are specific, measurable, attainable, realistic, and time‑bound. Owners can then turn these goals into project requirements that management can use as input.

The Business Planning stage process is reasonably well understood. It involves identifying and understanding an opportunity, getting alignment with stakeholders, considering alternate solutions and their various attributes, short listing the alternatives, and finally selecting one with which to proceed. Owners often believe that the immediate next step is to commission a project development team and to assemble a comprehensive plan that will deliver the unique product, service, or result that is needed to support the business plan. Owners often omit, however, consideration as to just what they are going to tell the Project Team that they want. If Owners think in business value terms early in the process, then one of the deliverables at the end of this business planning stage is a set of clear expectations and instructions to the project development team which form a comprehensive set of “Requirements.”

Too often, the Requirements articulation is left to the project team who have not been involved in the conceptualization of the business value to be delivered or the development of the conditions and capabilities that are required to be present in the final delivered product, service, or result.

This article is about those things that should be done early in business planning and project formulation to ensure that key stakeholders are completely aligned on the Requirements which, if satisfied by a project team, will produce the business value envisioned by the solution selected in the business plan. The completion of Requirements development is an input to the Project Charter which, when approved, signals the end of the Project Initiation Phase and the start of the Planning Phase.

Examination of these topics brings the project sponsors to a clear and articulated understanding of the business value that will be delivered by a well‑understood and defined project. In doing this, project Owners seek to avoid the most common root cause of project failure, which is not thinking early enough in the process about defining requirements.

2.    THE PROBLEM

Projects fail at an alarming rate.  Across industries, the studies are virtually unanimous that somewhere between one quarter and three quarters of all projects fail. The range is somewhat dependent upon the definition of failure and whether they are considering the delivery of business value or simply the achievement of objectives stated in project terms. These high failure rates are reported worldwide across industries and represent enormous amounts of wasted money.

In 2014, the Project Management Institute (PMI) reported on research that determined that poor project initiation is documented as one of the leading causes of project failure.¹ For many organizations, effective business analysis is not an integral part of their project work. As a result, projects are not delivering the intended business value. Fully one third of projects did not meet their original goals and business intent. Root causes were identified as:

• Inaccurate Requirements gathering; and
• Poor Requirements management practices.

These root causes were second only to changing organizational priorities as a root cause of project failure.

Independent Project Analysis (IPA) finds that four of every five oil and gas megaprojects are characterized as failures!² Studies of other sectors including minerals, chemicals, and power found that the failure rate was in the region of 50 percent. Projects that are successful are those that did a very thorough job in the front‑end. The root cause of these project failures is the omission of clearly defined and articulated Requirements for the project’s unique product, service, or result that are aligned with and driven by the delivery of business value.

Business value is a concept that is unique to each organization and includes tangible and intangible elements. Business value can be measured in short‑term or long‑term characteristics. It can include hard assets such as money or equipment, or softer assets such as goodwill, brand recognition, or public benefit. Whether an organization is a publicly traded company, a government agency, or a nonprofit, all enterprises conduct operations focused on achieving their goals and improving their organizational value.

Projects are used as a means of achieving business value through creating a unique product, service, or result that supports or enables corporate objectives and organizational goals required by an organization’s strategic plan.³ Failure to achieve a Requirement in terms of scope, or schedule, or cost is one thing, but failure to deliver business value defeats the purpose of the project and the organization’s strategic plan. If such failure happens often enough, it may threaten the viability of the business or the ongoing existence of the organization.

In formulating a project, Owners are of course spending their efforts and resources on development of an opportunity, markets, relationships, and the underpinning economics. However, Owners often don’t spend enough time and resources on clearly understanding the business problem and ensuring that they have looked at a full range of potential solutions. Furthermore, if a project is the best solution, Owners too often do not spend enough time on clearly articulating the project Requirements. It is the lack of identification and management of project Requirements that PMI and IPA have identified as a leading cause of project failure.

3.    DEFINING REQUIREMENTS IN A PROJECT

What are project Requirements? A project Requirement is a condition or capability that is essential to be present in a product or service, or necessary to satisfy the business objectives and organizational goals, consistent with the strategic plan and intended business value. Requirements may address various critical needs including:

• Business Requirements
• Stakeholder Requirements
• Solution Requirements
• Functional Requirements
• Nonfunctional Requirements
• Transition Requirements
• Project Requirements
• Quality Requirements

The list can go on and be expanded but these are basic criteria as defined by PMI in various publications. Clear Requirements are essential to develop and align the project objectives with the strategy of the larger organization.

Is the problem that we don’t know how to do this? Not at all! Most project sponsors are capable of taking a strategic plan with organizational goals and business objectives and then, in the context of a specific opportunity, composing them into specific Requirements, work statements, objectives, etcetera. The problem is that it takes time and resources to do this, particularly in a multi‑stakeholder environment. Business development leaders don’t plan for the time and resources, so the critical preliminary work gets deferred to later stages in the development. Have you ever heard … “it’s too early for that”? Rather than thinking early in project requirement terms, the thinking is deferred.

We know generally what to do; the problem is we just don’t do it. We have a feeling of being schedule driven and we have to get on with it! We often feel that we need to get past the business formulation part quickly and get on with the project initiation. We think they (the project team) can figure it out as they go. Exacerbating the problem, Project Managers have become accustomed to receiving poorly articulated instructions so that starting without a clear understanding of what Requirements need to be met has become routine. We lack the discipline to make sure we know where we’re going before we kick off the project team. Ready; Fire; Aim.

To come up with good Baseline Requirements, we need to build Requirements development and refinement into our business planning processes so that a well‑articulated set of Requirements is a necessary outcome of business planning. If we can get the Requirements well considered, and even approved by stakeholders before we kick off the project team, we will have the project team focused on the right outcomes and at the same time minimize a significant source of disruptive change and cost escalation.

Poorly defined Requirements lead to incorrect ideas about what the business planners had in mind, which means the product, service, or result may or may not solve the business problem. They lead to changing understandings on the part of the project team, which results in wasted effort, lost time, escalation of costs, and extension of schedules.

There is a well‑known relationship in which the ability to influence a project decreases and the cost of changes increases as the project moves forward. It is shown in Figure 1, which suggests that early in the process there is greater flexibility and the cost of changes is low. However, flexibility is lost as options are defined and chosen, and the impact of making a similar change later on escalates very quickly.

Figure 1
Escalating Impact of Changes as the Project Moves Forward

Successful projects have clear, well-defined project and business objectives. There is also a well‑documented relationship between the clarity of objectives and overall project success. Projects that are only “somewhat clearly” defined rarely succeed and even “fairly clearly” defined projects fail at a rate of 2 to 1.⁴

As a result, we need a methodology that will guide us to think early enough in the process about the project’s business value and lead us to develop well-articulated project Requirements.

4.    PROJECT LIFECYCLE

Projects have a “lifecycle” that can be defined in a series of phases that a project passes through from initiation to closure. As illustrated in Figure 2, all sequentially planned projects tend to have at least the following four phases:

• Starting the Project (often called Initiation)
• Organizing and Preparing (often referred to as Front‑End Loading)
• Carrying Out the Project Work
• Closing the Project

Figure 2
Discrete Stages of a Typical Project

The purpose of organizing the project into phases is so that development proceeds in an orderly fashion. During Initiation phase, the definition of the project is much more conceptual than in later phases. The approach of developing more details as the project progresses from phase to phase is called Progressive Elaboration.

The Initiation phase begins early in the life of the business planning/entrepreneurial stage of the project development. Its purpose is to:

• Set the vision for the project;
• Define the initial scope;
• Commit initial financial resources;
• Identify internal and external stakeholders who will influence the overall outcome;
• Align the project’s purpose with stakeholder expectations; and
• Officially authorize the project through the approval of a project charter.

The Initiation phase ends with the approval of the Project Charter, which provides clear direction from stakeholders to the Project Team about what is required and provides the approved basis upon which to begin work on the project.

There are a few key deliverables produced by the project Initiation phase. These include:

• Business Case
• Project Statement of Work
• Project Charter

The Business Case is the document that explains WHY we should undertake these initiatives and any project that is part of the solution. It contains the argument for the course of action recommended. It is typically a succinct document. The intended audience is the organization’s leaders, not the project team. Nominally, the business case should include at least the following:

• Problem or opportunity statement. The statement specifies the need for action.
• Analysis of the situation. The analysis reviews and demonstrates how the potential solutions support and contribute to the achievement of the organization’s goals and objectives.
• Recommendation. The recommendation presents the results of the feasibility analysis, constraints, assumptions, risks, and dependencies for each option, as well as the rationale for choosing a single option.⁵
• Evaluation. The evaluation provides the plan for measuring the benefits actually realized at the conclusion of the project.

The Statement of Work is a narrative description of products, services, or results to be delivered by the project. Product-oriented Requirements, at a high level, can be captured in this document.

The Project Charter is a document that describes WHAT the project is to deliver. It is an alignment document that authorizes the project to proceed on a specific mandate. The intended audience is stakeholders and the Project Team.

Nominally the Project Charter should include at least the following:

• Business need to be satisfied;
• Assumptions;
• Constraints;
• Customer needs and high-level Requirements; and
• A summary of the Statement of Work defining the product, service, or result the project is intended to deliver and related Requirements.

The business team should lead the preparation of these three documents. The Project Manager should participate as a functional member of that team.

So what we are looking for out of our project Initiation phase is good quality Requirements that address, at a high level, a full suite of stakeholder needs The Requirements must, as far as practical, be stated in tangible terms so that they can be implemented, tracked, measured, and achieved. At the beginning, it is necessary to define all Requirements at a high level so that they can be composed in a hierarchical fashion into more specific Requirements as progressive elaboration of the project unfolds. If a new high level Requirement is created later in the project, addressing it properly demands that the project reassess and ideally recycle back to the beginning. To avoid the chaos caused by change, and to avoid the cost escalation as well as schedule extension created by addressing change, it is essential to completely understand all the Requirements as the project is being initiated.

Understanding the Requirements means being able to articulate them succinctly and being able to document a description of how these Requirements support the business need for the project. Once again, this starts out at a fairly high level in the Initiation phase. This forms the starting point for progressive elaboration and further breakout as details of the Requirements become known. Before commencing to carry out the project work, a final detailed baseline of the Requirements is needed, which is unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to stakeholders. We have to begin with this end in mind.

Thinking early enough in project Requirement terms means ensuring that key deliverables are identified in the Project Charter and Statement of Work. Organizations are often good at understanding business analysis and the selection of alternatives. They are often less adept at comprehensively documenting their Requirements, resulting in insufficient Requirements gathering.

5.    WHO SHOULD PARTICIPATE?

Often, the business case is prepared by a business development team, which does not include a representative who will be accountable for the project (typically the Project Manager). The completed business case, after approval, is presented to the Project Manager with a “do this” instruction. A business case is a document for executive review and is unlikely to contain the many details and Requirements that came up during the development. This information, in particular the Requirements, is lost to the Project Manager, if it was ever specifically developed in the first place. Thinking early enough in the process about project Requirements means developing an approach aimed at preventing this outcome.

If possible, the future Project Manager should be a participant in the business development team. The Project Manager is an invaluable resource when initiating the project to deliver information on project risks and cost/schedule alternatives. Also, the Project Manager is the future steward and leader of the initiative. The business development team should make sure that the Project Manager will accept accountability for the risks and cost/schedule requirements. Most importantly however, the Project Manager will have an interest in driving the team towards articulation of clear Requirements.

The steps required are to:

• Clearly assign accountability for development of Requirements to the future Project Manager.
• Work towards a culture in which senior leaders’ expectations include the creation of clear Requirements by the business development team as a valued outcome.
• Develop an approach whose objective is to produce well thought-out, complete, and succinct Requirements. The plan supporting this approach would necessarily include allocation of time and resources to focus on Requirements development.

6.    THE REQUIREMENTS DEVELOPMENT PLAN

We will use the approach titled “Requirements Elicitation” described by PMI in their publication Business Analysis for Practitioners: A Practice Guide as a framework for describing what should be done. At the same time, this is offered as an example and we should acknowledge that there are many ways to set up an approach that ensures we are thinking early enough in project terms to understand the Requirements of stakeholders.

A central element to our approach is to decide whom we will consult and engage to determine Requirements. It is the stakeholder that we want to consult. “Stakeholders” refers to a diverse group of people not simply the organization’s Sponsor who asked for this opportunity to be investigated. Stakeholders are:

An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of the project.⁶

This working definition of a “Stakeholder” is used throughout the project in various contexts and necessarily encompasses a large group of people. When evaluating and developing Requirements this group is too large, and most do not have influence or interest at this stage. We, therefore, want to identify a sub group that we’ll call key stakeholders whom we will consult for Requirements and alignment.

All key Stakeholders may not have approval authority but it is essential to recognize that they may have influence. It is essential to bear in mind that the Requirements belong to the Stakeholders. It is their business value, they are the judges, and they determine success or failure at the end of the day. A Project is simply a means to an end. The Project Manager’s job is to satisfy Stakeholders and deliver the product, service, or result that supports or enables business value. If these people’s Requirements are not captured at this early stage they have the potential to surface as required changes or developments later in the project with the attendant negative impacts. Getting these Requirements included up front is also central to a Project Manager’s objective of minimizing change.

The key Stakeholders are likely to be found among the following group:⁷

• The project sponsor who is initiating and responsible for the project;
• Stakeholders who will benefit from an improved program or project;
• Stakeholders who will articulate and support the financial or other benefits of a solution;
• Stakeholders who will use the solution;
• Stakeholders whose role and/or activities performed may change as a result of the solution;
• Stakeholders who may regulate or otherwise constrain part or all of a potential solution;
• Stakeholders who will implement the solution; and
• Stakeholders who will support the solution.

Key Stakeholders who are external to the organization may be called upon at this time for necessary consultation. Informal consultations may be held, if including the Stakeholder as part of the review group would be inappropriate. However, if they genuinely are a key Stakeholder, excluding them from the Requirements development should be recognized as a risk for which a mitigation strategy may be needed.

Having identified which parties should be consulted, the next step is to be clear on why they will be consulted. The key Stakeholders are consulted to develop a recommended path forward which is documented in a Business Plan that is supported by a preliminary Statement of Work based on Requirements.

Recalling the introduction to this article, we related PMI’s findings that the root cause of project failure was:

• Inaccurate Requirements gathering, and
• Poor Requirements management practices.

Our objective of thinking early in the process in project business value terms means to recognize this risk and to respond to it by improving the Requirements gathering. This article focuses on the Requirements gathering and leaves the Requirements management practices during the execution of the project for a separate discussion.

The essence of Requirements gathering is to determine how and when to engage Stakeholders in elicitation activities as well as the methodology that will be utilized. The plan for Requirements elicitation should contain the following:

• The type of information that is to be elicited (Overall business? Operational? Technical or Functional?).
• Techniques that will be used to elicit the information?
• If there is a sequence, it should be identified (e.g., general survey first, then workshop).
• High level plan for each session including:
  • Specific objectives of each technique or session;
  • Participants by Role or Name; and,
  • Participant instruction, types of questions, or other material to focus people on the information being sought.
• The type and timing of follow‑up with participants.

There are numerous facilitation techniques that can be used and numerous references on how they can be put to use. Some examples include:

• Brainstorming;
• Document analysis;
• Facilitated workshops;
• Focus groups;
• Interviews;
• Observation;
• Prototyping; or
• Questionnaires and Surveys.

Leaders should remain alert to problems that could arise which might reduce the effectiveness of eliciting the Requirements. Each problem may require creativity and emotional intelligence to resolve. The types of issues might include:

• Conflicting perspectives and business needs from different stakeholders.
• Assumptions about what the solution should be, without first understanding the problem.
• Resistance to change, does Requirement elicitation itself require change management?
• Inability to step back from preconceived notions and solutions or the desire to press fast‑forward because the answer is assumed to be obvious.
• Lack of access to the right Stakeholders, either genuinely because of constraints or artificially because they decline to become engaged.
• Lack of knowledge or experience on the part of Stakeholders.

The elicitation is an iterative enquiry. This work should be done at the beginning of the project when that business analysis and plan is being assembled. There will be opportunities to further or progressively elaborate as the project gets underway. It is also important to consider when to stop further elicitation and how to identify when all of the Requirements that drive business value have been identified.

Indicators of when to stop may include:

• The results are approved;
• An information model that guided the elicitation has been completed;
• The information that is being provided is redundant at the level being worked;
• There are no new top priority Requirements; and,
• How the defined business value is achieved is firmly supported by unambiguous Requirements.

It is essential to document the output of the elicitation activities. The documentation serves as a reference to what was requested by Stakeholders and what they think is needed to accomplish the business purpose or maximize business value. It is, therefore, a primary reference and input to the project team in defining what will and will not work, and what is and is not appropriate. It gives the Project Manager the basis to move forward with a minimum of disruptive changes which all cost time and money. It gives the Project Manager a baseline with which to maintain a stakeholder engagement plan in which Requirements are progressively elaborated throughout development ending in a verification that the Requirements given by stakeholders were provided in the final product, service, or result.

The documentation of Requirements covers a broad array of issues and knowledge types:

Business Requirements tend to be the goals, objectives, and higher‑level needs of the organization. This might include economic, social, and environmental objectives.

Stakeholder Requirements document the needs that each stakeholder might have. The “must haves,” the “could haves,” the “can’t haves,” and the “we don’t wants.”

Solution Requirements are the functional and non‑functional features, functions, and characteristics of the product, service, or result. This might include production capacities, reliability requirements, product specifications, user interfaces, maintainability, and many other parameters.

Transition Requirements define how the organization will move from today’s state to a future state in which the product, service, or result is in use. These Requirements may address the way an organization switches over to use of a new facility, or about training, human resources, or organizational management of change.

Project Requirements describe how the project will be conducted, including:

• How accurate does the estimate of schedule and cost need to be before approval?
• Requirements in terms of compliance to specifications or quality standards (ISO9000).
• Organization expectations in regards to safety and environmental performance of the project.
• Requirements that implement social or regulatory policy such as hiring practices, purchasing practices (e.g., local content), or working with landowners.

Quality Requirements are the condition or criteria by which successful completion of a project deliverable will be validated. The possession of a permit issued by a regulator, or the performance speed test record of a cargo ship are each examples.

At times, guidelines are helpful in assessing a Requirement. The following considerations are offered as a first‑pass checklist. Typically, a Requirement should be:

• Written as a complete sentence (or sentences) including a subject, active verb, and object, and stating any conditions.
• Clear and unambiguous.
• Precise and concise. Each written Requirement only contains one Requirement, not a series of nested Requirements. If it can be broken into two, it should be.
• Consistent with other Requirements without contradiction or redundancy.
• Correct as confirmed by the relevant stakeholder.
• Measurable so that its attainment can be quantified and objectively validated or tested.
• Traceable so that it can be used in Requirements tracking and management as well as change management. Any Requirements that are associated with higher level or over‑arching Requirements should be documented as such. The Stakeholder(s) who is the source of the Requirement is identified so that the genesis of the Requirement can be traced.

7.    SUMMARY

Not thinking early enough in a project lifecycle about project Requirements is a root cause of project failure. The research on this by leading authorities in project management is conclusive.

Project failure in this context is not failure of the project to meet its own objectives but rather the failure of the business to realize the business value or business objectives intended through undertaking a project.

Projects are developed in phases and the most important of these is the Initiation phase in which the business has the opportunity to undertake the critical thinking that defines those things they want a project to achieve. During the Initiation phase, business planners should identify the conditions or capabilities (Requirements) that are essential for the product, service, or project end result to deliver the intended business value.

Thinking early enough in the project lifecycle about defining Requirements means including an objective in the Initiation phase that high-level Requirements are gathered for later use by the project team. A deliberate elicitation process is needed to gather the Requirements. With the Requirements in hand, project leadership is then ready to explain the mandate of the project to the project team. Thinking early enough in the lifecycle process about project Requirements helps to avoid a common root cause of project failure.

About the Author

Douglas A. Bassett, P.Eng., PMP, FCIP, was a Principal with Long International and passed in September 2020. He had over 35 years of Canadian and international consulting experience involving construction project management, project leadership and project governance/review. Mr. Bassett was a seasoned project leader. During his career, Mr. Bassett was involved in all types of oil and gas energy projects with a primary focus on oil sands and refinery facilities, offshore fixed and floating drilling and production facilities, and conventional onshore production facilities. Mr. Bassett’s accomplishments included serving as project leader on Canada’s first offshore development production platform, project leader in a successful alliance to develop a major oil sands mine, and governance leader of project approval reviews for oil sands and offshore mega projects. He was an Instructor of Project Management at the School of Business, SAIT Polytechnic. Mr. Bassett was a graduate in Civil Engineering from Carleton University in Ottawa, Ontario. For further information, please contact Long International’s corporate office at (303) 972-2443.

---

¹     Project Management Institute, PMI’s Pulse of the Profession: The High Cost of Low Performance, 2014. http://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2014.pdf.

²     E. Merrow; T. Haidar, “4 Out of Every 5 Oil & Gas Megaprojects Fail. But Why?” The Boardroom, 2013. Oil and Gas Today. https://www.oilandgasiq.com/strategy-management-and-information/podcasts/the-boardroom-4-out-of-every-5-oil-gas-megaprojec?&shownewswindow=1&mac=OGIQ_Events_Title_Listing_2011&utm_source=OilGasIQ&utm_medium=Eloqua&utm_campaign=IQ_Misc&utm_content=dlc&utm_term=dlc.

³     Project Management Institute, “Projects and Strategic Planning,” A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5th ed., Pennsylvania: Project Management Institute, Inc., 2013, p. 10.

⁴     P. Luan, “How to Avoid Project Trainwrecks,” Oil and Gas Facilities Magazine. Vol. 5, No. 2, pp. 25-28, April 2016.

⁵     Early in the project initiation process, it may be preferable to go forward with more than one option and a risk-based plan to select a single option at a specific milestone.

⁶     Project Management Institute, “Projects and Strategic Planning,” A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 5^th Edition, Pennsylvania: Project Management Institute, Inc., 2013, p. 563.

⁷     Project Management Institute, Business Analysis for Practitioners: A Practice Guide, Pennsylvania: Project Management Institute, Inc., 2015.

Copyright © 2019 Long International, Inc.