Tag Archives: requirements gathering

Your Project Will Change

You led your team through a very thorough requirements gathering process. There was brainstorming and walk-throughs of the product functionality. Multiple groups contributed and reviewed the results. Additional analysis and review went into deciding which of the requirements would really make it into the scope. There was plenty of intelligent debate. And now finally, the project scope document has been signed.

Everything has been agreed upon and there will be no changes. Right? Wrong! Your project will change. You might begin to think, “What does she know? She wasn’t there. She did not see all of the work that went into agreeing upon our project scope.” You are right. I have not been following you. Still, your project will change.

What you have done is helped to ensure that the changes that occur either stem from unforeseeable circumstances or are truly useful enhancements or result from changes in the organization or political climate. Your project will change.

Even with the best planning possible, random things can occur. Previously stable business partner can go out of business and cause you to seek out new suppliers. A certain type of material may not hold up to testing. A new regulation may be imposed on your industry. A product may not function as designed. Testing might reveal a flaw. Sometimes unforeseen events bring about change.

As the project moves along, your team members will develop a better understanding of the work that is being performed. Your customers will develop a better understanding of what they really need. New ideas will evolve. You are not going to tell all parties to stop thinking, to stop coming up with new ways to make your product or service even better. You want the good ideas to keep flowing. If a change to the project is valuable enough, then a change request should be approved and the change should be incorporated. Your project will change.

To your surprise, your project sponsor who seemed happy and stable in her position announces that she has accepted a position outside your organization. Her replacement supports your project, but has different ideas about the project objectives and about what you and your team should really be creating.

Say it with me now, “My project will change.”

And it is going to be all right. The amazing work you did with your requirements and your scope document was well worth the effort. By spending time gathering requirements and agreeing upon scope, you have created a good baseline for the changes that will come. You and your team will recognize change. You will be able to have intelligent conversations about what these changes mean to your project.

Let the changes come, you are ready for them.

Requirements Gathering? Elicitation? No…

George Bridges, PMP

Requirements Development

A business analyst does not gather or elicit requirements.? They develop them.

In fact collecting requirements from stakeholders is a subtle problem for most people who are responsible for managing the requirements process.

The problem with gathering requirements

The problem with gathering requirements is that it implies that you already know the solution to the problem.? By collecting information, we determine the “real” problem(s).

Once we have confirmed the problem(s), we will move into the phase of developing requirements that will solve the problem(s) for the current project. What a Business Analyst or someone acting in that capacity should do is collect information from the stakeholders. This person should elicit the “right” information that will lead to the development of the requirements.

To do this, you need to have an elicitation plan that will guide you through the process of requirements development. ?So take the information you get from the stakeholders, analyze that information so that you can develop, analyze and write good requirements.

If you need a framework to work from, I suggest you check out the Business Analysis Body of Knowledge (BABOK), published by the International Institute for Business Analyst(IIBA) ?(www.theiiba.org) ….. more on this subject in my next blog.

[Editor’s loud mouth]

If you are reading this right now, what do you think of George’s distinction here between developing versus gathering or eliciting? Is it just semantics, or is this an example of language influencing practice?? I like George’s approach, mostly because I want to be sure new business analysts and project managers realize that you can’t just go to the customer and ask for their requirements.? (Well, you can….)? There’s a process of refining and as George points out, developing, those statements and documentation until they reflect what the project will truly seek to fulfill.

[/Editor’s loud mouth]