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.
One problem I have with progressive project planning is that in our organization, we have resources being shared across many projects, and we need to assign the resources up front. If the project plan constantly changes, the resource utiliziation gets very complicated, as we need to get reapprovals for the resources, everytime schedule changes, as those resources were probaby committed to work on other projects. There's a domino effect everytime project plan changes. Saving Changes...
Rich LeggeProject Manager| Haemonetics Software SolutionsWoodstock, Il, United States
Which came first requirements or the estimates? (Chicken or Egg)
PMI's PMBOK is not specific to a single industry such as Software. Treating Requirements as a project can work, if customers want to wait/fund.
Using PMBOK verbiage -
Initiation starts with selection of PM and finishes with development of a preliminary scope statement.
Planning starts with creation of a detailed scope statement and finishes with stakeholder approval followed by kick-off.
Execution starts by acquiring team and "doing all the work activities"
Monitoring and Controlling happen while you are executing.
Closure starts once you have completed the product or service defined by the product charter/scope and finishes by releasing the remaining resources.
In each organization and perhaps each project size, whether the requirements for the software product is a project by itself, part of planning, or part of execution is part of the excitment and fun.
Sorry no cookie cutter answer. In Project Management and Software devleopment, one size never fits all!!!!!
In your case I would suggest you start by developing a definition for "requirements", i.e. are there lots of requirements for a new piece of software or are the requirements merely adding functions to a previously existing piece of software.....
> 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 have a small questions - without having the customer requirement, how the PM can prepare the scope for the project?
The whole concept of "requirements gathering" is pretty specific to the IT community. Not every project goes through a phase called "requirements gathering". Construction projects have early design phases where they do initial drawings and models, which are reviewed with the client, but they are not usually called "requirements gathering".
Very often I go through the initiating work on a project (writing the charter) with only a limited understanding of the full requirements, even on IT projects. The scope of the project at this early stage might only include a business-level overview of the problem to be solved and the financial constraints around the solution we must devise. Later on, we begin the process of requirements gathering.
Six Sigma projects are another example where client or end-user requirements come quite late. DMAIC phases call for early steps where you brainstorm ideas for improvement and measure existing processes. It is not until the "A" or Analyze phase that you are typically gathering end-user requirements.
In other cases, I have worked as a contractor where I was given quite detailed requirements at the very start of my work to design and implement a system. In these cases, though, there were early phases of the project that I was not involved with. In these early phases, the team probably did not understand their own requirements fully, and they needed to go through a requirements gathering phase to create the document I received.
It is definitely possible for the PM to get an early scope statement, even without having the full customer requirement. Sometimes a senior executive has walked into my office with a one-page memo and said, "Fix this." In this case, I have a problem statement and no requirements yet. Even so, in a matter of 15 minutes we have been able to set some of the scope parameters for the project:
* What is the senior executive willing to spend (time and money) to solve the problem
* What is the core business issue (in a paragraph or less)
* What resources do I have authority over to solve this problem
* How many departments in the company need to be involved
> The whole concept of "requirements gathering" is pretty specific to
> the IT community. Not every project goes through a phase
> called "requirements gathering".
I really dont think so. Requirements gathering is nothing but understanding the customer "NEED". This is generic and not really specific to IT. This is even applicable to a sales guy - he needs to understand what you (customer) want!!
> Construction projects have early
> design phases where they do initial drawings and models, which
> are reviewed with the client, but they are not usually
> called "requirements gathering".
Definitely in construction project also, customers will have their own need (ie requirements). Once you get the requirements, architects design the solution. This is simillar to software industry, where a software architect first develop the architecture for the solution.
> Very often I go through the initiating work on a project (writing the
> charter) with only a limited understanding of the full requirements, > even on IT projects. The scope of the project at this early stage
> might only include a business-level overview of the problem to be
> solved and the financial constraints around the solution we must
> devise. Later on, we begin the process of requirements gathering.
That is because the customer is interested to share his complete requirements with the vendor whom he is going to work with. To identify a suitable vendor, who can confidentaly deliver the solution for his requirement, client will share minimal (mostly non-confidential information) with many vendors and ask them to submit a proposal. Based on the proposal (technical evaluation and commercial evaluation) the client selects a vendor, signs NDA and share all the information.
> Six Sigma projects are another example where client or end-user
> requirements come quite late. DMAIC phases call for early steps
> where you brainstorm ideas for improvement and measure .
> existing processes. It is not until the "A" or Analyze phase that you
> are typically gathering end-user requirements.
Six Sigma is a methodology applied to solve very specific problem (often called as requirements).
> In other cases, I have worked as a contractor where I was given
> quite detailed requirements at the very start of my work to design
> and implement a system. In these cases, though, there were early
> phases of the project that I was not involved with. In these early .
> phases, the team probably did not understand their own
> requirements fully, and they needed to go through a requirements
> gathering phase to create the document I received.
It again depends on the type of engagement - if it is fixed cost, then it is the responsibility of the vendor to gather the complete set of requirements and deliver the solition. In case of T&M, the client might just say this is my requirements, you can start with the software design.
> It is definitely possible for the PM to get an early scope statement,
> even without having the full customer requirement. Sometimes a
> senior executive has walked into my office with a one-page memo
> and said, "Fix this." In this case, I have a problem statement and
> no requirements yet. Even so, in a matter of 15 minutes we have
> been able to set some of the scope parameters for the project:
> * What is the senior executive willing to spend (time and money) to
> solve the problem
> * What is the core business issue (in a paragraph or less)
> * What resources do I have authority over to solve this problem
> * How many departments in the company need to be involved
The reason why the senior executive has only 1 page information is, the client is not interested in sharing his exact problem with everyone. The client is trying to identify a correct vendor who will solve his problem. To evaluate the vendors, he gives some minimal information!
I think we must "agree to disagree" at least a little, Vivekanandan. I agree completely that you can stretch the word "requirements" to cover all of these situations, it is not a common part of the vocabulary of the project teams that I see. When someone says "requirements gathering", they are usually talking about a piece of software.
I have found that "requirements" jargon will put off non-IT audiences, when talking to groups of project managers. Non-IT project managers use different terms and often do not have a project phase devoted to the effort of defining the project requirements. Often the work is spread across many phases and activities, and has many different names attached to it. I can see your point that the activities all involve understanding the customer need, but they do not call it "requirements gathering".
Also, the senior executive with the one-page charter is not holding back any information, in my experience. He or she may not know or care about the details. Senior managers often see the overall issue or challenge, and leave it to others to define the solution. In some cases that is a good, strategic role for them to take. The project is started with no clear requirements because the executive has no idea of what they are -- he or she just knows the desired business outcome (revenue, customer satisfaction) or problem.
> I have found that "requirements" jargon will put off non-IT
> audiences, when talking to groups of project managers. Non-IT
> project managers use different terms and often do not have a
> project phase devoted to the effort of defining the project
> requirements. Often the work is spread across many phases and
> activities, and has many different names attached to it.
Fine, if "requirements" is a jargon for non-IT , I think simple term like Goal/Objective can be used. I think for a project like - marketing campaign, they will have set of goals/objectives for their project. Still now I have not come people not using the work "requirements"!
Best Regards,
Vivekanandan M Saving Changes...
Jeff DahlProject Leader| Edward JonesMaryland Heights, Mo, United States
I am a purely business side project leader and I routinly use "requirements" when defining the scope of the project. Now these requirements translate into work flow changes that the product will affect. So far I have not had any issues with the "jargon" when discussing the project with the team.
I use "objective" as the base statement for the result of the project. An example is, "The objective of this project is to replace the legacy system X with a new updated system."
This is normally the item I receive from my department leader and I go off and begin to define the requirements to support the objective. After defining the requirements from all involved stakeholders I will return to the steering committee for approval. At this point we as a firm have not invested a significant amount of time or internal cost.
