When planning out a project in phases, one often gets stuck at the percent of project time that should be allocated to requirements needed and wonder how much business requirements as a percentage of project time should be determined in the project initiation phase.
Instead of just throwing out a number let’s begin by looking at requirements planning as a project itself.
The goals of our requirements planning project include:
- Determining the needs of our end-users / customers
- Identifying the overlap with other areas that may cause redundancy or conflict
- Identifying any risks
- Determining critical success factors
- Prioritizing the users’ needs
Gathering, understanding and documenting the users’ needs are the key tasks to creating an effective design that produces a result that works for everyone.
Some of the things we wish to address through our requirements planning include:
- Determining the feasibility of the overall project (if a formal feasibility study was not already done)
- Assessing how well the project satisfies strategic goals
- Minimizing rework necessary to bring the project into alignment with the goals
- Maximizing the use of company resources
Further, by identifying:
- How well the project fits into the corporate structure and meshes with the company’s goals and objectives
- The risks and challenges facing successful completion of the project
- The resource impact on the company and its organizations while delivering the project
We can better prepare people from the executive level to the end-users for the project’s execution.
The typical output from our requirements planning project may include:
- A clear and concise executive summary of the requirements
- One or more suggested strategies for the overall project
- The as-is and to-be processes in enough detail to direct the designers
- A well-documented change management process
- One or more suggested design approaches
Requirements Planning Approach
Once we understand the purpose of our requirements planning project, we can begin to look at our approach.
We begin by gathering requirements from our users. Typically, sessions are set up to talk with the various roles affected by the overall project. Communication is critical in these sessions. The facilitator of these sessions must know how to pull useful information from the users and feed back what is heard in order to verify the requirements.
The overall goal of these sessions is to gather and document realistic and achievable requirements correctly.
People representing various areas will become a part of the working sessions:
Department Managers - These are the managers in the areas directly affected by the results of the project. They know the specific business needs to be incorporated into the requirements.
Users - These are the people who have “hands-on” contact with the results of the project. Each individual may have a different way of fulfilling their role with the tools they have. And each person may have a different view of how the requirements impact them.
Technology Personnel - This may include the IT staff, IS personnel and support staff. These people have knowledge about the infrastructure and processes that support a given area of the business.
Sales and Marketing Personnel - Depending on the project, these individuals will be needed to understand market-driven issues and concerns.
A Reiterative Process
The process of gathering complete and accurate requirements requires a cycle of:
- Obtain the requirements
- Document the requirements
- Validate the requirements
You will obtain the requirements through your interview sessions and analysis of current processes, procedures and technical documentation.
The documentation of the requirements should be done as the information is coming in, with an additional “clean up” task to make the requirements easy to understand.
The validation of the requirements happens when you present the users with your documented requirements and ask “Is this what you meant?” This critical feedback loop is important to reduce the risks taken on by the project.
The Final Analysis
With requirements in hand, we now can review them to determine the level of risk and feasibility. From the detailed information we can decide on an appropriate design and approach.
And, based on more specific information than we had earlier, we can now refine the budget and time estimates.
While this looks like a lot of effort and many steps, all of this must be accomplished regardless of the size and scope of the project you are starting. Whether it is a new report request from an accounting department supervisor or a corporate directive to consolidate the multiple CRM and ERP systems into one global entity, the answers derived from your requirements planning are important to the successful completion of the project.
Now to answer the question, “How do you set business requirements as a percentage of the project time?…your timeline is done when you have it right.
Having it right means the information you obtain from requirements planning can be used to reduce, or at least, understand the project risks, satisfy the needs of the users’ and corporate goals, and not shut down the company’s operations to execute the project.
Looking at the trends for projects of all sizes, one finds that from 20 to 30 percent of the overall project time is spent in the requirements phase.
The lower end of the range is useful for projects that have few unknowns:
“I want to add a column to this report that is the average of the first two columns.” May only need 15 to 20 percent of the time in requirements.
The more unknowns, the more time will be needed:
“We want to streamline our CRM and ERP operations in the US, Europe and South America to run on a single platform.” Will probably take many resources and 30 to 35 percent of the project time to reach a level of comfort that the goals can be met without crippling the company.
The savvy project manager will begin by drafting a plan with 25 percent of the project time set aside for requirements and adjust as the discovery phase makes the project goals clearer.
Proper time and attention to requirements will benefit a project greatly. Insufficient time spent on requirements almost always increases the risk of schedule and budget issues, often deep into the project when it is most costly to recover.
- “Requirements Management Plan Example”, Rational Staff, IBM, May 2001, http://www.ibm.com/developerworks/rational/library/4421.html
- Image Credit: Project Stages - Wikimedia Commons/Department of Veterans Affairs, Office of Information and Technology / Public Domain License
- Project Times, “Requirements Management 101”, Elizabeth & Richard Larson, December 2010, http://www.projecttimes.com/articles/requirements-management-101.html
- Other Source: author’s own experience