Projects Begin Before They Start: Defining Project Requirements


The following topics are discussed in this article: early definition of project requirements, project stakeholder requirements, the project charter, elicitation of project requirements, and project requirement types.


Projects fail at an alarming rate, but project Owners can improve any project’s chance of success by defining the project requirements early. Project requirements are those features that the stakeholders want incorporated in the final project and by which the completed project’s success is measured. Inaccurate or incomplete definition of project requirements is a significant root cause of project failure.

In many projects, clearly defined requirements are absent because when entrepreneurs are considering business opportunities, evaluating options, and prioritizing alternatives, they often don’t stop to consider their next step as leaders. That next step is to instruct a project team on the specifics of what they are supposed to deliver. Frequently, there is an assumption that the team either implicitly knows how to define requirements for a project, has determined these requirements already, or that they’ll accurately develop those details later. Often, both assumptions are false. The result is that the project team commences the planning work without clarity about what products, functions, and features the project is to deliver.

Projects are living things. They change as they grow. But if the project team has not been involved in a project’s early development during planning, they draw their own conclusions about what is important for the project; and the project definition evolves without the project team being aware of critical requirements that all too often do not become apparent until later in the project’s development. The unavoidable result is either cost escalation from revisions to meet previously unrecognized requirements, or important requirements that don’t make it into the projects. Both of these are the first steps towards project trouble.

But if we determine a project’s requirements as its originating ideas are being generated, and make the capture of these ideas a priority, then we can take steps to avoid this difficulty. First among these steps is engaging the leading members of the project team (at the very least the Project Manager), in the early‑stage requirements‑gathering work. The project team’s understanding of the project as a whole is essential to its success.

And we also need to fully understand what the requirements are and how to capture them. To do this, we often have to overcome a too commonly occurring organizational culture of considering project requirements management as minor details and/or leaving them to be considered later.

A project requirement is something that project stakeholders deem essential to be either part of the finished product or absent from it in order for the project to be a success. This definition includes business objectives and organizational goals consistent with the strategic plan and the intended business value. This definition will be elaborated on later in the discussion; for now, it is important to note how intimately connected the definition of “requirement” is with that of each “Stakeholder.”


The minimum definition of a “Stakeholder” is a person who, during the initiation stage of the project, formulates the business opportunity – and establishes the business value – that makes the project possible. We might call such people the “Core Stakeholders.” But in the more comprehensive picture, stakeholders are everybody who may affect, be affected by, or perceive themselves to be affected by a decision, activity, or outcome of the project. While it is important to be mindful of this larger group, the focus at the beginning is to get the requirements that create business value.

There is a big prize if we define and capture requirements for a project right from the beginning, and a big loss if we don’t. Shortcomings in this area have been well documented as a leading cause of project failure. The Project Management Institute (PMI) and Independent Project Analysis (IPA) have concluded that somewhere between one quarter and three quarters of all projects fail due to inaccurate requirements gathering (PMI), or, as put more broadly by IPA, poor front‑end work.

While a project’s success is generally seen as the production of the desired business value, and success is achieving what stakeholders want, “success” alone isn’t enough to provide a clear goal. Too often, projects don’t have a well‑developed understanding of what stakeholders want because typically, few project teams sit the stakeholders down and say, “Now let’s go over what you want specifically.” Perhaps ironically, unless someone draws stakeholder’s minds to focus on this question and specifically elicit their requirements, the likelihood is that they could never actually state their requirements at the outset either – or perhaps, without being asked the question, even know how to define requirements for a project.

But there are two times when a stakeholder is most likely to know the project’s requirements. One is when they are considering alternative solutions in business planning. If we wait until after the project gets going and we ask stakeholders to recall all the things they were thinking at the time they formulated the project, we will get at best a partial answer. This is one of the reasons to not delay focusing on articulating stakeholder, and thus project, requirements.

The other time is when something happens that doesn’t meet the requirements. Stakeholder requirements never go away whether they have been stated out loud or not – or whether they have been understood by those who must achieve the requirements. If the project team doesn’t recognize the requirements at the beginning, sooner or later (less or more expensively) they will eventually surface.

Those who implement a project call the requirements that are recognized after the project gets going “Changes.” Changes cost money and cause delay, disruption, and rework. And the later changes are recognized, the larger their impact.

On the other hand, the stakeholders call requirements which are recognized after the project gets going, “Things you forgot.” These things may not have been even brought up in discussion, but they turn out to be necessary to produce the intended business value. So without venturing into the “need to have” versus “like to have” discussion around requirements, we can say that our customers/stakeholders want them. Our job as Project Managers is to help the stakeholder’s requirements realistically be achieved. That’s difficult enough when everyone knows what the requirements are, but if the requirements are not acknowledged or incorporated during the project’s definition, the delivery of the desired business value may be incomplete at best; at worst, not achieved at all.


What every project needs is a methodology that will guide those involved to think early enough in the initiation stage in project terms and lead to well‑articulated requirements. The initiation stage of the project begins early; it is the business planning/entrepreneurial part of the development. Its purpose is to set the vision of the project aligned with producing a specific business value, define project purpose in alignment with stakeholders’ expectations, and officially authorize the project to commence with the development of a Project Charter for approval.

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. Its intended audience is both stakeholders and the project team. The Charter should capture all of the key requirements that the project team is to deliver and provide a reference to the project management document that contains the statement of work and all of the requirements that have been developed.

The requirements described in the Project Charter should emerge from the project initiation stage and address, at a high level, a full suite of stakeholder needs. The team working together at the initiation stage should aim to state the requirements in tangible terms, which are terms that make it possible to implement the requirements, track their progress, measure their fulfillment along the course of the project execution, and determine the point at which they are achieved.


The methodology to accurately gather well‑articulated requirements for the Project Charter is one of elicitation. Through elicitation, the project team must seek to draw out or educe from stakeholders their requirements.

This methodology needs a plan which should describe the anticipated method and resources required to deliver high quality requirements by the end of the initiation stage of the project. The elicitation plan should address what types of sessions and techniques will be used for requesting and receiving the requirements from stakeholders. It should discuss how follow‑up will be conducted with the participants. Most importantly, the expectations of senior leaders, which set the culture in which requirements are captured early in the process, should be evident and participation should be seen as compulsory.

There are numerous facilitation techniques that are broadly applicable to elicitation and that can be included within the plan. Readers will be familiar with brainstorming, focus groups, and interviews, to name a few.

Since the term “requirements” covers a host of issues, it’s useful to break them down into topics at the outset of an elicitation session, such as brainstorming. The range of topics one might see in a brainstorming session could address business drivers, operational drivers, technical solution drivers, future expansion, or transition from one type of operation to another. The topics may also include how the project is to be operated in regards to safety management, political, environmental, and regulatory concerns, or cost control.

At times in such sessions, simple procedural guidelines can be helpful in articulating and assessing project requirements. One helpful guideline is to insist that all requirements be stated in full sentences: thinking a concept through to the point of complete expression often helps refine the thinking about it. Another guideline is that requirements be specifically stated – in measurable terms – and that each captured requirement is unique: if a requirement can be broken into two, it should be.

Team leaders should remain alert to problems that could arise during the requirements elicitation process that might reduce the effectiveness of discovering and articulating project requirements. Each obstacle will require creativity and emotional intelligence to overcome. Conflict resolution among competing or even conflicting requirements should be expected. A frequent issue, however, that team leaders may need to address is the potential for a culture of complacency as busy team members defer focus on requirements until later in the project. This is coupled with the desire to press fast‑forward, because “the answer is obvious.” Accepting the excuse that “it’s too early for that” is how many leaders set the stage for later problems.

Elicitation, then, is enquiry, and it is iterative. The more of this work that gets done early, the better. Clearly, not every requirement will be brought forward at this stage, and there will be opportunity to further or progressively elaborate in the project stages to follow. It is important, then, to develop a sense of judgment about when elicitation has identified all of the essential requirements that drive business value.

It is always possible, even with the best “front‑end work”, for a new high‑level requirement to be created later in the project. But addressing new high‑level requirements properly does not mean making a field‑level adjustment and carrying on. It 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 that any new requirement be integrated into the overall requirements established as the project was being initiated. Maintaining a coherent understanding of the complete project requirements is essential.

Accurately gathering requirements means to be able to articulate them succinctly and describe how each of the requirements individually and all them together support the business value of the project. A complete understanding of the project requirements may often be lacking due the project development structure, including the documents by which information is passed from one level of project development to another, and the personnel who comprise the decision‑making bodies at each project development level.

One such structure concerns the Business Case, a document that explains why a project should exist rather than explaining what the project must deliver. Often, the Business Case is prepared by a business development team that does not include a representative who will be accountable for the project (typically the Project Manager). And when such a completed business case is presented (after approval) to the Project Manager, it is usually with the “do this” instruction to begin the second project development stage – planning. While that arrangement may appear maximally efficient, the compartmentalization is a barrier to communication. It serves the purpose of providing the fewest number of directives possible, and it doesn’t “clutter up” the project team’s mind with “big picture” concerns. It gives the Project Manager only what they “need to know.”

But Project Managers (indeed Project Teams) often need to know more than what is presumed that they “need to know” because of “Project Events” – those unanticipated moments in every project that demand adjustment and require reference to the complete picture to be understood and coped with. The Business Case is a document for executive review and is, thus, unlikely to contain the many details of the requirements contemplated during the initiation of the project which may only manifest themselves later in its implementation. The project requirements, then, may be lost to the Project Manager, if they were ever specifically developed in the first place.

In the best case, the future Project Manager is a participant in the business development team. The Project Manager is an invaluable resource when initiating the project to deliver information on project risk and cost/schedule of 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 accepts accountability for the risks and cost/schedule. Most importantly, however, a Project Manager involved in the generation of the project plan will have an interest in driving the business development team towards articulation of clear requirements.

It is essential to document the results of the project requirements elicitation and gathering work. The documentation serves as a reference to what was requested by stakeholders and what they think is needed to accomplish the business purpose and maximize business value. The documents produced are a primary reference and input to the project team in defining what is and is not likely to work and what is and is not appropriate to try. It gives the Project Manager the basis to move forward with a minimum of disruptive changes which all cost time and money. It thus gives the Project Manager a baseline with which to maintain a stakeholder engagement plan in which requirements are progressively elaborated throughout development. Lastly, it sets the stage for the project closeout and completion stage, ending in a verification that the requirements given by stakeholders were provided in the final product, service, or result.


The documentation of project 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. These include, as noted earlier, economic, social, political, 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. These 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.  They include requirements about the way we switch over, or about training, human resources, or organizational management of change.
  • Project Requirements describe how the project will be conducted. They answer questions such as:
    • How accurate does the estimate of schedule and cost need to be before approval?
    • What are the requirements in terms of compliance to specifications or quality standards (ISO9000)?
    • How does the project meet organizational expectations in regards to safety and environmental performance of the project?
    • Are there requirements that implement social or regulatory policy such as hiring practices or purchasing practices (e.g., local content), or working with landowners?
  • Quality Requirements are the conditions or criteria by which successful completion of a project deliverable will be validated. The possession of a permit issued by a regulator or the speed test performance record of a cargo ship are each examples.

The requirements must be documented in language that is unambiguous, specific, and measureable. The documentation must be in a form, whether database or listing, that supports frequent referral and maintenance as part of an ongoing requirements management practice. The documented requirements form an essential baseline upon which is founded the development of the project scope, schedule, and ultimate cost.


This article has emphasized the need for both early and thorough thinking about defining and determining project requirements in order to increase the chances of project success upon completion. Such early and thorough thinking, which should involve the Project Manager at the Initiation Stage, increases the chances of proper delivery of project requirements and addresses a known primary root cause of project failure.

In drawing attention to Project Initiation and accurate requirements gathering, this article may be stating what many successful project teams already do. However, as we’ve seen from the rate of project failure, it may also be stating what many unsuccessful project teams thought or believed they were doing, but failed to do adequately.

How, then, can Project Teams think differently? By considering that requirement development starts even in the earliest stages of project development. A project begins before it starts. Before the Initiation Stage, all projects begin with a call for their requirements.  But the Initiation Stage, in which we define the business opportunity and the project requirements is not just the “Let’s do something” stage. During the Initiation stage, what is being considered shapes not just the project requirements, but defines, documents, and clarifies the understanding of the requirements and, thus, influences the probability of achieving project success.

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.

Copyright © 2019 Long International, Inc.


Experience Matters

Our experts are ready to help.

Our extensive international experience includes large, complex, grass roots, revamp, and reconstruction projects incorporating conventional-phased, fast-track, and EPC turnkey concepts.