Set in stone

Peer to Peer Two seasoned professionals discuss how to convince stakeholders to nail down project requirements from the start.

Set in Stone

What benefit do project professionals find when defining project requirements early on?

Michael Boyle: It helps you understand what the individuals are trying to achieve and understand assumptions and constraints.

The requirements fulfill a double role of first recognizing and then continuously verifying the project's assumptions and constraints. This scenario played out again for me recently when I assumed all departments were looking for the same type of functionality. The requirements depicted something much different.

Joseph L. Mayes, PMP: Varying or ill-defined project requirements will—not may—have an impact on project schedule and scope, which ultimately impacts cost.

Flexibility and cost are directly proportional. The greater flexibility you have going into a project—the flexibility to modify requirements throughout the project—the greater the ultimate cost.

Plus, if stakeholders don't tell the project team specifically where they want to go, everyone's at risk of wandering down a few rough country roads with no guarantee of getting any closer to the desired destination.

How do you encourage stakeholders to dedicate the necessary time and effort for setting requirements?

Mr. Mayes: I explain to the stakeholder that he or she can pick two of the following: good, fast or cheap. It illustrates the need to be clear on quality, time and budget requirements. Time is immutable, and quality needs are usually static, meaning the only variable is cost. Present stakeholders with the notion that clear requirements are the means by which project managers are held accountable, and that costs are directly tied to how clearly requirements are stated.


Michael Boyle is the managing director of portfolio management at Procurro Solutions in Vienna, Austria.


Joseph L. Mayes, PMP, is director, IT security, at Universal American Corporation in Lake May, Florida, USA.

Stakeholders who refuse to define what they want end up with projects that are doomed to failure or experience at least significant cost overruns, which, for a project manager, is the same thing.

—Joseph L. Mayes, PMP, Universal American Corporation, Lake May, Florida, USA

Mr. Boyle: Following the adage, “It's not the message but the messenger,” I often find a better messenger if that's what's needed.

It helps to have a qualified business analyst responsible for collecting requirements. This allows the project manager to properly understand the data collected; recognize tendencies, patterns, contradictions and synergies; and ensure proper scope definition, work breakdown structure and, eventually, the project plan.

How do you handle a stakeholder who refuses to provide requirements?

Mr. Mayes: Cash the check early and update your résumé.

My experience is stakeholders who refuse to define what they want end up with projects that are doomed to failure or experience at least significant cost overruns, which for a project manager, is the same thing.

In the LinkedIn Project Managers group, Oliver F. Lehmann, PMP, a project management trainer in Munich, Germany, asked:

What is your experience regarding original stakeholder requirements over the life cycle of a project?


Mr. Boyle: It depends on the stakeholder, as inevitably all stakeholders don't hold the same importance within all projects.

I establish a diagram to visualize where stakeholders can be plotted within an importance axis, and based on the depiction, the path of escalation is determined:

  • Super user: This individual not only has good command of the application in question, but is a go-to person for others who run across difficulties. Often, this individual knows more about the application than the help desk or even the product manager.
  • Influencer: Very often, the employee does not have a managerial position but has been employed by the organization for a number of years, has worked in various departments and has mastered a strong internal network.
  • Decision-maker: There is inevitably a de facto and a de jure decision-maker. The de facto decision-maker either controls the budget or holds a veto power; the de jure decision-maker holds power within his or her department.

How can you nail down requirements from multiple stakeholder groups?

Mr. Mayes: In addition to business end-users, the project sponsors, contracting staff and other stakeholders have a voice and often override authority in the process. I use a three-step process:

  • Communicate with management-level stakeholders to gain a common understanding of the process for, and importance of, effectively gathering requirements.
  • Communicate with the development team to nail down what they need to know to deliver.
  • Communicate with end-users to explain our requirements-gathering process and its importance to overall project success.

Mr. Boyle: [When there are differences in opinion concerning requirements,] compromises should take place behind closed doors, and project managers should emphasize to each stakeholder the importance of the initiative to his or her department and the overall organization. PM




Related Content