In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure

The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape

At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.

Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

• Linear or Incremental 20% 
• Iterative or Adaptive 70% 
• Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together

I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.