Whether it's higher productivity, increased competitiveness or improved public service, project managers must understand what a project aims to achieve. Requirements analysis helps them do just that.
During this process, project managers break down stakeholder requests, examine the timeline and budget—and then identify any incompatibilities that might exist between expectations and reality. This kind of deep dive helps avoid unwelcome surprises later.
Yet too often project teams don't take analysis far enough, says Filipe Altoe, vice president of engineering solutions at Cal-Bay Systems, a test systems provider in San Rafael, California, USA. They formulate a general idea of what stakeholders want but don't quantify those outcomes.
Inaccurate requirements gathering is a top-cited cause of project failure, according to PMI‘s Pulse of the Profession™ research. That's because collecting this information—and getting people to agree—can often seem like an insurmountable task, he says. “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.”
The first step in requirements analysis is to decide which tack to take. To choose the right approach for a given project, consider the project goals, the organizational culture, and the strengths and weaknesses of each approach related to the specific project:
Agile: “Agile requirements are centered on progressive elaboration,” says Jesse Fewell, PMI-ACP, PMP, enterprise agile coach, Washington, D.C., USA. Rather than hammering out all of the details before the project starts, this discipline focuses on defining only the specific requirements related to things the team is going to work on right away and only a high-level scope for the rest of the project. This keeps the project team from getting bogged down in the planning process, Mr. Fewell says.
“Projects often suffer from pressure to know everything before doing anything,” he says. “But as you can imagine, this can cause delays.”
Because details may change as the project moves forward, this rolling-wave approach encourages project managers to embrace collaboration and change. Agile's flexibility makes it especially useful on knowledge-based projects that rely heavily on discovery and face a variety of unknowns, Mr. Fewell says.
“Successful projects respond to change, rather than follow the plan regardless of what changes around you,” he says. “High-level goals are often stable, whereas the most common changes on knowledge projects are in the detailed requirements. Agile methods are designed to implement that change control [configuration management] directly into the requirements analysis process.”
Systems Engineering: This is a tiered approach to requirements analysis. Starting at a high level, this methodology first focuses on understanding what the sponsor is looking for, defining what research has already been done and, similar to other approaches, separating must-have features from nice-to-haves. It often involves some sort of visual modeling that facilitates stakeholder feedback.
The second tier prioritizes requirements based on which of the three primary constraints are most important to the sponsor: schedule, budget or scope. “There is usually an education process that needs to take place, as not all clients understand the triangle of constraints—that when one of the three vertices is changed, at least one of the other two vertices will need to change, as well,” Mr. Altoe says.
Finally, the analysis turns to risk. The prioritized requirements are each given a grade that corresponds to risk probability and impact. This process helps the project team decide whether a prototype needs to be created, what activities will require the most time and whether certain requirements should be revisited with the sponsor to reduce the project's overall risk, Mr. Altoe says.
“Usually, when we speak in the language of money and schedule, the client becomes more motivated to pare down requirements that carry extra risk,” he says.
Lean: Two of the main pillars of the lean approach are customer satisfaction and waste reduction. When viewed through this lens, the requirements analysis process involves close collaboration and targeted documentation, says Waffa Karkukly, PhD, PMI-ACP, PMP, managing director of Global PMO Solutions Inc., Toronto, Ontario, Canada.
“Lean is used best when clients are willing to give the time required to work closely with the team to elaborate on the requirements,” she says. “If customers are informed and engaged upfront, you can achieve maximum collaboration.”
The first step of this approach is meeting with the stakeholders to identify and elaborate on all requirements that are valuable and relevant. Stakeholders should also agree to a set of criteria that defines each requirement's success. During the project, a lean product backlog is maintained, with deliverables released incrementally to allow for frequent reviews and fresh collaboration across the stakeholders.
“Establishing testing for each requirement means there are no surprises for the customer,” says Dr. Karkukly. “Documenting requirements isn't done for the sake of documenting. We want to reduce waste by documenting things in a selective manner, and we want to drive satisfaction by collaborating interactively across all stakeholders.”
Value Engineering: In this discipline, the elicitation process, at its most basic, involves gathering requirements through a series of stakeholder interviews or meetings. Over the years, though, this elicitation stage has evolved into a process called value metrics.
“Making a distinction between requirements and attributes can be crucial in decision-making,” says Peter C. Feldman, director at Value Management Strategies Inc. in Almont, Michigan, USA. “Absolute requirements are binary. For example, either a new vehicle meets a certain safety standard or it does not. Almost every product, process or service has a list of absolute requirements that must be met. In contrast, attributes use scales ranging from unacceptable to ideal and have a range of potential values.”
Working with stakeholders to distinguish between requirements and attributes can be especially helpful, Mr. Feldman says, in prioritizing different project components. “Once requirements and attributes have been established and their priorities identified, they can be used to measure and compare any step that's being considered in a rational way,” he says.
Learn the Language
One challenge project teams may face when conducting requirements analysis is bridging the gap between technical requirements and project goals. Systems engineers and project managers may talk in terms of solutions and logistics, while business leaders and other important stakeholders generally speak of end results.
CASE STUDY
Widening the Lens
Strong requirements analysis can mean the difference between project success and failure— particularly when a large number of stakeholders are involved.
When Roberta Miglioranza, PMP, Grupo Severiano Ribeiro, Rio de Janeiro, Brazil, oversaw her company's transition from analog to digital movie projects, stakeholders assumed it would be a simple equipment switch. “They didn't realize how it would impact the technology or building design,” she says of the project, which began in August 2012 and is still ongoing.
To identify how the change in technology would impact facility design, the team relied on 3-D modeling, one-on-one stakeholder interviews and focus groups.
The team interviewed stakeholders responsible for the specific company outcome to gather and validate the requirements for renovations.
“Since all renovations are unique in scope, we interview functional managers to understand their needs,” she says. “We gather all the requirements and evaluate the project scope to understand the mutual implications and validate project requirements with functional managers in interviews, according to their responsibility.”
Those interviews were followed by a focus group that included all of the project engineers, along with the head of IT and the architect responsible for project design. Each participant was called on to explain the requirements related to his or her piece of the project and how the project's proposed changes would affect the outcome, she says. The engineer responsible for electric and data infrastructure brought up concerns about the size of the electricity generator and Internet speed needed for the building. The head of IT discussed the impact of the new requirements on the company's IT management. “Our team was there to mediate, document and follow up on the implementation of these requirements,” she says.
Finally, 3-D prototypes helped her team validate requirements with the operational team and gain approval from the board for construction changes. “3-D images are especially useful for non-engineers to understand and evaluate the end result,” she notes.
This combination of requirements-gathering tools guided the team and the stakeholders in identifying critical needs in the project plan. For example, the focus group discussions helped them adapt the building design to add new cable connections for Internet access and additional space for racks, while eliminating the need for certain corridors and wiring.
“It allowed us to identify and validate the changes required,” she says. Those requirements were factored into the facility design template and are currently being rolled out in new theaters across Brazil.
“The more we understand the requirements related to the projects, the better we can help integrate the different technical knowledge involved and plan more effectively future projects,” she says. This helps to hone the project plan for the current project and delivers continued benefits for future related projects.
At the beginning of a project, stakeholders often make broad statements about outcomes and solutions they think are requirements but are not, says Victoria Kumar, PMP, project management office program manager for the North Carolina Office of the State Controller in Raleigh, North Carolina, USA. “As a project leader, you can't say, ‘I don't know what you mean,’” she says. “You have to help them communicate their goals in more detail.” Leveraging a few useful tools can help streamline these conversations:
Stakeholder analysis: This process is used to identify key stakeholders—from executives to end users— and the roles they play in the project. Establishing this list ensures their needs are considered up front and factored into the risk-assessment process, and that the right people participate in decision-making. Stakeholder and user interviews, focus groups and use cases provide greater insight into what the project must deliver, the stakeholders’ vision for the project and how they prioritize outcomes.
To enlist stakeholder involvement, Ms. Kumar's team holds requirements workshops at the beginning of every major project. The project team interviews stakeholders, holds requirements analysis sessions and hosts group conversations to define, hone and validate requirements. Group conversations can facilitate this process by giving stakeholders a chance to build on each other's ideas or identify hidden problems.
CASE STUDY
Change of Plans
Whenever project managers review requirements with stakeholders—whether it's during planning or in response to a change request—they should take the opportunity to highlight interdependencies. It's one of the best ways to help stakeholders understand how easily small changes can knock a project off course.
“When you take the time to educate stakeholders about requirements, it can eliminate a lot of problems,” says Filipe Altoe, vice president of engineering solutions at Cal-Bay Systems, a test systems provider in San Rafael, California, USA.
As part of the launch of a multimillion-dollar data-monitoring installation project in June 2012, Mr. Altoe's team met with the five key stakeholders. Before work even began, they all agreed on a set of requirements that could be achieved within the schedule, scope and budget. Halfway through the project, however, the client announced the new lab was also going to be used by a local university research team, which added dozens of new stakeholders who needed to be consulted.
The researchers had a new set of requirements that pushed the team back to square one, Mr. Altoe says. Even worse, Cal-Bay had agreed to the financial and schedule terms of the contract before the new stakeholders came on board. “They still wanted us to execute the project within the constraints of the time and budget, but with an entirely different scope. All they saw was that they gave us several million dollars, so why couldn't we give them what they wanted?”
Rather than plowing ahead, Mr. Altoe's team stopped the project and spent several weeks reworking the requirements. During the process, he devoted time to explaining to stakeholders how changes directly impacted the schedule, budget and outcomes of the project.
Then they sat down together to decide what could stay and what had to go. “It took a lot of horse trading,” he says. “If we gave them something, they had to give us something back.”
By the end of the negotiations, the team was able to adapt the scope to meet the new stakeholders’ needs while sticking to the original budget. To accommodate the additions, six months were added to the schedule, with project completion slated for this December.
“The lesson learned is that you have to take the time to educate stakeholders, internally and externally, about requirements management,” he says. “If they understand what they are up against, they will be more thoughtful about the changes they make.”
“You have to ask a lot of questions about what they want it to do and how they want it to work,” she says.
Visualizing: Talking about requirements, however, can only get a team so far. Sometimes it takes visual tools, including 3-D models, prototypes and storyboards, to close the gap between how stakeholders describe what they want and how project teams define those deliverables, says Charles Was-son, owner and principal of Wasson Strategics, Columbia, Tennessee, USA. “In traditional engineering, the project team writes technical specs, but the customer might not be able to understand them,” he says. “It's critically important to write requirements using unambiguous statements that result in only one interpretation.”
Taking time to create visual models of the project using drawings, computer simulations or even simple cartoons helps create clarity for non-engineers and visually oriented stakeholders, ensuring everyone is on the same page.
There are three advantages for using these prototypes, says Roberta Miglioranza, PMP, expansion manager for Grupo Severiano Ribeiro, a motion-picture exhibition company under the Kinoplex brand in Rio de Janeiro, Brazil. “It garners design feedback from stakeholders who are not familiar with a project before the walls are up. It saves construction time and cost. And it helps manage stakeholders’ expectations, giving them a baseline they can understand.”
By revising the requirements analysis methods used to construct a new cinema, Ms. Miglioranza's company was able to trim construction time from the industry standard of eight months to only five months. “The drastically improved time-frame for execution convinced the stakeholders that the time spent on requirements analysis was worthwhile and led to better results in the long run.”
Unified modeling language (UML): UML is an object-oriented software language that lets software engineers create a visual map of the relationship between requirements and business processes. The use of UML gives project developers a blueprint for what needs to be included in the project scope and shows stakeholders how their requested features will be accommodated. This blueprint can clarify stakeholder expectations on engineering projects with added complexity, Mr. Altoe says. “It gets a visual representation in front of the stakeholders of what we believe the system should do,” he says.
This is particularly useful in complex technology projects that have a large number of complicated requirements, adds Mr. Altoe. “All stakeholders care about is what the system can do,” he says. “This helps them visualize what you are talking about.”
Most teams use a combination of requirements analysis tools based on their project management style, the organizational culture, and the needs of the team and the stakeholders, says Ms. Miglioranza.
“There is certainly more understanding of the requirements if more tools are used to create and validate them,” she says. “Stakeholder interviews help get personal, in-depth analysis about requirements. Focus groups 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 understand the project.”
One way to keep stakeholders focused is by prioritizing requirements within the constraints of time, quality and budget. This gives them a clearer understanding of what to expect within the allotted budget and gives the project team a decision-making framework.
“In development, if you can't satisfy every requirement, some things need to be deferred,” Ms. Kumar says. “But the developer shouldn't be the one to make those decisions; the stakeholders should.”
Connect the Dots
Even with the best planning, sometimes change is unavoidable. Whether due to unforeseen circumstances such as market shifts or opportunities such as access to new technology, changes must be assessed to determine how they will impact existing requirements. “A formal change-control method brings stability to the requirements management process,” Mr. Wasson says.
To avoid underestimating the ripple effect that a single change could have on the cost, risk and timeline of all other project components, project teams should document requirements down to the smallest manageable business functions so they can easily see how one action impacts another. Then the project manager can revisit that document during regular project review meetings and whenever a change request is made.
The document types can differ. Mr. Altoe's team uses documents standardized on UML to track these connections.
“UML has different abstraction layers that allow the representation of multiple dimensions of the project requirements as well as allow for a nice way to go only as deep as needed for a particular project,” he says. “Once we determine the initial analysis has been completed with UML, we usually translate the requirements into written specifications to facilitate the creation of traceability documents that tie the requirements to the design, implementation and quality documents.”
But, he warns, such documentation can go overboard if project teams try to delve into too much detail. “There is a point of diminishing returns; however, that line is not easy to identify,” he admits. “In my experience, one starts seeing the point of diminishing returns when specific documents stop being maintained.”
And because requirements are active throughout the project life cycle, project managers must keep them updated.
Not only does this help the project team manage changes to the project plan, it also allows the team to track the project's evolution. “That helps immensely at the time of the project post-mortem meeting and assists other project managers in the organization who may refer to this project in the future,” Mr. Altoe says.
Even the best project plans and most detailed requirements documents need this oversight. “Requirements are always in a state of flux, and that's something project managers have to embrace,” he says. “To expect all requirements to be perfectly defined and static prior to starting is a recipe for failure.” PM
