Under PMI's 5 process groups, Initiating, Planning, Execution, Controlling, and Closing Processes, where is requirements gathering process done under?
It's funny because requirements gathering is such an important aspect of a project, yet PMI is unclear where this takes places (or I could just be missing something).
I would guess that you need to have a project plan before you start gathering requirements, and since output of Planning is Project plan, you start collecting requirements in the next process group, which is Execution process group.
However, it's very hard to come up with an accurate Project Plan until you have the detailed requirements.
I don't think gathering requirements before initiation is the right step. Gathering requirements is a very intensive time consuming effort, and you don't want to get started on that before you decide whether to do the project or not.
I am leaning more towards gathering requirements after planning, and modifying the plan if the gathered requirements lead you to that path. Saving Changes...
Evan SandersProject Manager| Health CatalystUt, United States
I believe you can see the results of requirements gathering in both the initiating and planning process groups.
In the initiating group, the process for Develop Prelimary Project Scope Statement would cover high-level requirements.
In the planning group, the process for Scope Definition would cover more detailed requirements. The Scope Definition is shown as something that occurs after the Project Plan is developed. This indicates that requirements gather is a part of the project, and is addressed in the plan.
That makes sense Evan, except I think Scope definition should be completed before the Project Plan. Saving Changes...
Evan SandersProject Manager| Health CatalystUt, United States
Tony - I agree. It makes sense that the scope has been defined before the project plan can be finalized.
The PMBOK 3rd Edition view on this appears to be different. It shows the Scope Management activities, including Scope Definition, as occuring after the creation of the Project Management Plan. It's possible that the underlying reasoning is that Scope Definition is considered to be part of the project, therefore the Project Plan should exist before the team begins this activity.
Even if we are strictly following the PMBOK, there is still leeway for defining scope prior to finalizing the project plan. The PMBOK shows that the Project Plan can be updated based on the output of Scope Definition, and it also shows that Preliminary Project Scope Statement would be created prior to the Project Plan.
In practice, I have always found that the scope needs to be defined at least to a reasonable degree before the project plan is developed, so I think we are in agreement. For those who are studying for the PMP exam, it is important to understand the PMBOK's view, which appears to be that Scope Definition follows Project Plan Development.
Saving Changes...
Robin GoldsmithPresident| Go Pro Management Inc.Needham, Ma, United States
This is one of many areas where the PMBOK is inadequate, largely because it's based on inadequate understanding of requirements. There are two types of requirements: Business/User/Stakeholder Requirements whats which provide value when accomplished and Product/System/Software Requirements which describe one of the possible ways how presumably to meet the REAL, Business Requirements. Scope mainly creeps when REAL Business Requirements have not been defined adequately; but the creep usually is perceived as changes to the Product Requirements.
The key to reducing creep is to define scope in terms of high-level REAL business deliverable whats, which involves some data gathering and analysis and needs to be done as part of Initiation before the project definition, budget, and schedule are established and cast in concrete, followed by the Project Plan for carrying it out. Execution of the implementation project then should include further data gathering and analysis to detail the REAL business requirements which have been selected for implementation; and such requirements detailing generally is performed iteratively.
Saving Changes...
STEVE ROLLINSChief Project Strategist| ALLPMO Network Inc Fort Mill, Sc, United States
Hello Tony,
Requirements gathering for any project should start before the project is initiated in the form of a business case or something similar. The PMBOK 5-Phased Life Cycle allows for a funneling-effect that is top-down as requirements are defined and detailed.
Great care should be exercised to complete requirements before actual test case development is started. This makes the role performing the Requirements Development (Planning Phase) the most critical strategic resource(s) to the project. If the requirements are not developed and approved in time, all subsequent work tasks that are dependent will slip. It is this hidden consequence that makes the PMBOK 5-Phase Life Cycle to general for most critical projects.
Tony, I recommend looking hard at the process groups again. Also, consider the purpose of your project. PMBOK Guide really has nothing to say about the order of work on any type of project. It just notes the relationship between the type of activities typically performed in well-managed projects.
Here are a few examples to illustrate:
1. Your project goal is to develop a piece of software. Requirements have already been defined when you are assigned as a project manager. In this case, requirements are done before the initiation of the project.
2. Your project goal is to produce a set of requirements for an off-shore team. Your responsibility is to create the requirements; an off-shore team will manage the creation of the system. Requirements gathering would consume the main execution work in your project.
3. You are developing software from a set of vague requirements. You have to define the requirements and then create the software. In this case, "User Requirements" is probably one early phase in your project. You will go through all five process groups in that phase, and you will go through all five process groups in the phases that follow.
4. You are developing a minor improvement to an existing application using Agile techniques. You will probably do requirements gathering work, but it might not be a separate phase or even a separate activity. You gather requirements in close concert with the end-user while creating prototypes, mock-ups, and the working code. Requirements gathering is probably pretty invisible, and mostly impacts the planning, initiation, and execution process groups throughout the project.
Remember that the process groups are repeated over and over again, in a cycle, throughout the entire project. You are constantly closing and initiating new phases. Where to put the work of "gathering requirements" depends on the definition of your project.
Because "requirements" affect the project and product scope, the discovery of the requirements will impact the initiating and planning activities. If there is work to be done to gather, research, and document requirements for your project, these are usually tasks that you must execute. Often I have to initiate and close a requirements-gathering phase in software development projects.
In my opinion, there is no set order for this work. PMI does not list requirements gathering because it does not address software development projects specificially -- this phase of work does not even exist in a construction project or a pharmaceutical clinical trial.
If you want guidance on when to do that type of work, you should look for a software development methodology. PMI PMBOK Guide is not a methodology. Methodologies like SDLC, Agile, Extreme, RUP, and so on will make definitive statements about when and how you should perform requirements gathering work.
I hope this helps. I know I wrote some things that are in conflict with other comments below. I submit these ideas humbly, based on my own best opinion and understanding. I welcome feedback and disagreement from everyone here. Saving Changes...
Alex, I think what you said makes perfect sense in that requirements gathering can be considered a project in itself in PMI.
The question is, does anyone actually go through all of the project cycle in PMI (Project charter, WBS, Project plan etc.) just for requirements gathering phase? How do you do a CBA on a requirements gathering project ? :)
I actually found a website that maps each of the PMI processes to SDLC steps, and it actually maps scope definition as equivalent to requirements gathering phase. That also made some sense to me as well, although this is probably not what PMI envisioned it.
I cannot speak for others, but I do plan the requirements-gathering phase in detail. I have never run a whole project on requirements gathering, so the full WBS includes many activities including requirements. Still, the WBS is broken down into major work-packages involved in the requirements work. Typically we break down by functionality, department, major functional areas (admin vs. user), feature list, or sometimes by module. We estimate, plan, and schedule the work in detail.
I like to leave the coding and design work as a high-level plan until the requirements are complete. In fact, we are usually estimating and re-estimating design as various requirements are completed. I like a "progressive elaboration" approach to estimating and planning for these projects. The more we learn about requirements, the more detail we can add to the following phases of software development.
I do not usually do a cost-benefit analysis on my requirements work. It is possible to cost-justify requirements, though. Look at the studies that show the cost of finding and fixing an issue in the requirements phase vs. design, code, test, or production. The costs dramatically rise with each step in most studies. Fixing problems in requirements may be an order or magnitude or more less expensive.
As you can imagine, I do not like to map SDLC to PMI process groups. Mapping "requirements gathering" to "scope definition" is a little dangerous. It depends on how you define the project. Often these comparisons also confuse project scope with product scope. User requirements are about product scope, typically, and project scope must be derived from them for design and coding work. There are many ways to look at these issues, though, and I do not pretend to have all the right answers. Saving Changes...
