With more than 70% of project failures being attributed to requirements gathering, why are we still using the same techniques and expecting different results? Requirements need to be discovered before they can be “gathered” and this requires a robust approach to analyzing the business needs.
The failure of a project due to requirements means the project manager could have come in under budget and on schedule, but failed to understand the most important factor of all. What did the customer REALLY want? We can deliver the best, most user-friendly software or beautiful building possible, but if the right requirements weren’t identified, we can still fail.
We increase our chances of gathering the right requirements by using a list-to-visual process.
We increase our chances of gathering the right requirements by using a list-to-visual process that is looked at two different ways: the forward-backward pass. Mathematicians use it to smooth out equations and we use it to verify early and late starts of a schedule. The premise is that the boundaries of each step are discovered when looking at the same flow, two different times. Additionally, the combination of a list format and a visual format helps varying thinking processes and retain information.
The forward pass in the visual process flow establishes the basics – what steps are taken during an action. The backward pass is much like asking a person to recite the alphabet backward. The customer is forced to consider each step individually without jumping to the next item in the memory line. When they are focusing on one step, critical information can be discovered. We do this by asking questions like:
- How long does this take?
- Is anyone else involved?
- What can go wrong with the process during this step?
- Why is this step important?
You get some invaluable deliverables from this approach including a way to justify the requirements, a documented process and a consensus on requirements for going forward.
“It’s not my fault, the customer didn’t identify that they wanted this at the beginning!”
We hear these statements when a project manager justifies a troubled project to management and we need to look at why excuses not to gather requirements don’t work.
“The customer changed their mind half way through and I had to rework everything! Of course I am not on schedule or budget!”
Even if they can show the history through change orders, they can’t explain why the end product is so vastly different from the original scope.
“Why do we need to involve all of these people? I can just tell you what we need.”
Another common response from clients is that they do not have the time or budget to do the in-depth requirements gathering sessions we propose. Management feels strongly that it already knows what the project should deliver.
“The requirements were already identified, I just followed orders!”
Realistically, the project manager may not be part of requirements gathering. We may be handed the requirements as part of the RFP or from another project or department. It is easy to say that we did not have control over the requirements and therefore can’t be held liable for their success.
If we encounter issues along the way, it is our job to identify the consequence and communicate it to the right people.
The issue with this thinking is we ARE responsible for the project’s success by asking the right questions to ensure we do our due diligence to identify who or what makes that project successful. If we encounter issues along the way, it is our job to identify the consequence and communicate it to the right people. Project management is iterative and we need to constantly identify and validate the very foundation of what creates the project scope.
The requirements will be tracked and the success criteria confirmed during the project. Use a “Requirements Traceability Matrix” and other requirements documentation throughout the process as new requirements are discovered, changes to the project occur and other questions are brought to surface. Remember, the goal is to meet customer needs and the requirements are the way to do that.
Although seemingly time consuming to use this approach, these documents can also be used during and after the project as part of company assets:
- During the project, re-trace and update the swim lane and action document to use for training and knowledge transfer.
- After completion of a phase, revisit the documents to see if requirements were met. Go through the same exercise, does it still take “x” days? Does this still happen? etc.
- After the project, go through the same process to show a decrease in duration, resolved issues, etc.
- When it’s difficult to measure ROI, the before and after of these documents is a great way to visualize the benefits of completing the project. You can show a decreased duration, limited issues and risk and overall decrease of inefficiencies and lag time.
Next Post: Creating a Strong Requirements Gathering Approach – Part Two