One of the leading causes of projects not meeting their objectives is the failure to fully and completely define the project requirements. One of the leading causes of failing to define project requirements is a not understanding the full range of stakeholders that have an interest in your project. Most of what is written about project management addresses how to plan and manage delivery of a stated set of requirements however the elicitation and documentation of requirements is typically assumed or understood without guidance on who needs to be involved with actually establishing the requirements.

In 2007 Brazil won the bid to host the 2014 World Cup. “We’ve had six years to complete these projects, but those on the political sphere couldn’t make decisions. It wasn’t a problem of labor shortages or resources. It was a problem of stakeholder management,’ said Farhad Abdollahyan, project manager, Sau Paulo Brazil.

“When you do requirements gathering, it can be difficult to uncover all the information needed from all the different stakeholders. It’s one of the primary reasons projects fail,’ says Filipe Altoe, project manager, San Rafael, California.

Stakeholders are all of the people that are impacted or influenced by the outcome of a project or at least think they are. Just because we might not think someone is a stakeholder doesn’t mean that they won’t view themselves as a stakeholder anyway. Stakeholder analysis is the process used to identify key stakeholders from executives to end users to consumers and the roles they play in the project. Establishing this list ensures their needs are considered up front and factored into the project plan.

An effective way to enlist stakeholder engagement is to facilitate requirements workshops at the outset of the project. The workshops provide an opportunity for project team members to interview key stakeholders and define, add specificity and validate requirements. Besides giving stakeholders and team members a chance to build on each other’s ideas or identify hidden problems early in the game these workshops help build a collaborative project culture that will expedite negotiations when change requests are received that will impact schedule, budget and deliverables.

All too often project managers and teams make the mistake of jumping into a course of action without investing the effort to understand the real needs of the business and who has a vested interest in the outcome. The structure of the project organization typically assumes that the project sponsor knows all the requirements and has the final say regarding what’s in and what’s out. The reality is that the project sponsor is absolutely a stakeholder, and will almost certainly have a perspective and a say in the requirements of the project. The pitfall is that the sponsor is one among many stakeholders and it’s the “many” part that can kill us and cause a failed initiative.
Interviewing stakeholders provides details about the requirements. Recently I led a project where increased market share was an executive management requirement. This led to include sales and marketing as stakeholders who asked, “What is the baseline that will be used to measure if the requirement has been realized and how much increase to the baseline is required within what timeframe to determine success. If market share is 25% and we increase market share to 28% within two years are we successful?” These conversations create a common sense of understanding.

Use cases help stakeholders understand how the end user is going to experience the result of the project. And prototypes help stakeholders visually see how the project is being designed and developed. Iterative design and development is a prototype methodology for web based applications where stakeholders must sign off on the design and functionality of each screen prior to launch. In many projects not all requirements can be delivered and some things need to be deferred. But the developer shouldn’t be the one to make those decisions, the stakeholders should. By visually seeing what the end user experiences stakeholders can make better decision tradeoffs because they can see the ripple effect of how one action impacts another.

Gaining agreement on requirements up front is essential if we are going to deliver successful projects in the eyes of all of our stakeholders. The purpose of defining requirements is to have one single agreed-upon list of what everyone wants to see out of the project. To do this, we have to get the full perspective of each stakeholder’s requirements on the table, and be very objective about where disagreement exists.

As project managers we must embrace that requirements are always in a state of flux. To expect requirements to be perfectly defined and static prior to starting the project is not realistic. It is reasonable to expect that during the project differences of opinion will emerge over what the project should do. As changes occur they must be assessed to determine how they will impact existing requirements. This will create disagreement regarding approving or denying the change.

Where disagreements are found it is essential that we resist the urge to ignore them and hope they go away. We simply can’t sweep them under the carpet; doing so just gives them incubation time during which they will likely escalate from disagreement into full-on battle.

Negotiating these disagreements is not easy, nor is it fun. It is absolutely essential, however, to avoid conflicts. As project managers we have to be prepared to confront and address the disagreements as we find them. Moreover, we don’t own the solution our stakeholders do. What we do own from the benefit of our unique vantage point and perspective of looking at the project as a whole is facilitating the resolution of the problems early and quickly.