Harnessing The Chaos; Are Portfolio, Project and Requirements Management Interrelated?

The idea for building a colossal dam in the southern part of Egypt had been considered by the country’s president Gamal Abdel Nasser since the mid-fifties. There was a number of reasons why he and the rest of the Egyptian government thought it would be a great benefit to their country: the desire to come up with an impressive deed after defeats in the war with Israel and the Suez crisis, the need to maintain steady levels of the Nile throughout the year and the aspiration to produce more electricity to support the increase in production of cane sugar, cottons, maize, fertilizer, steel and textiles.

After the Western powers withdrew their promise of aid for the dam, the Egyptians turned to the Soviet Union for financing and expertise. The Soviet government, for its own political reasons, duly obliged and the project got underway.

While managing to capture the “technical scope” of the project fairly well, the planners somehow completely neglected to talk to the real customers, the people who would be most affected by this venture. As a result, a multitude of issues, both tactical and strategic in nature surfaced soon after the completion of the dam in 1971.

High Aswan Dam (NASA photograph)

Firstly, the construction of the power plant led to the flooding of the temples of Abu Simbel which eventually had to be lifted above the water and repositioned at a great cost to the government of Egypt.

 

 

The second disappointment was the realization that the hydro plant associated with the dam would not produce sufficient amounts of electricity for Egypt’s growing economy. The situation was made worse by the ironic fact that, because the Nile was no longer flooding the valley and depositing rich alluvial silt on the agricultural fields, the country was faced with an increased demand for fertilizer production.

And finally, the construction of the Aswan Dam lead to a significant increase in the population of snails, the carriers of a dangerous and debilitating disease – bilhazria. It has been estimated that a third of Egyptian population is now suffering from this ailment.

It is quite fascinating to analyze this project from three different angles: project management, portfolio management and requirements engineering (scope definition). Let us start with the scope definition. As was mentioned before, the planners of the Aswan Dam neglected to consider the needs of the real customers of the project – the people living in the valley of the Nile. The simple fact known pretty much to every schoolchild in the world – that the ancient Egyptian civilization flourished thanks to the Nile flooding the valley and depositing its fertile silt on the shores of the great river – has somehow eluded the planners of this project. The neglect to consider this little detail is mind-boggling, to say the least.

It is also quite obvious that risk management area of project management was also completely lost on the planners. For example, it is very surprising that they managed to completely ignore the possibility of flooding of the Abu Simbel temples. The catastrophic rise in the occurrence of the bilhazria, although not so easily predicted, should have also been foreseen.

The issues on the portfolio management side are therefore deeply rooted in the failures in the areas of project and scope management. Had the requirements elicitation stage been conducted properly, the additional costs associated with the soil depletion could have been avoided. Had there been better project risk management, the cost of Abu Simbel’s relocation could have been reduced. The impact of the disease is very difficult to assess but it is safe to assume that the fact that one-third of the population suffering from a serious disease is devastating

It is not very shocking therefore that considering all of the above-mentioned blunders, the financial costs alone of the Aswan Dam, both short-term and long-term, by far outweighed any benefits to the Egyptian people.

Unifying Project Management, Portfolio Management and Requirements Engineering

To be honest it was the multiple cases of utter confusion that I have found myself in during my career that prompted me to write this article. The problem is that I, as probably most IT professionals, have been trained to think that there are several very distinct and independent sciences out there: project portfolio management, project management and requirements engineering[¹]

As a result, in my career as a project manager, requirements engineer, process improvement consultant and especially course instructor I have relied on my own experience as well as the multitude of great books, schools of thought and methodologies developed in portfolio management (R. Cooper, S. Bonham and H. Levine), project management (PMI, S. Berkun and S. McConnell) and requirements engineering (K. Wiegers, R. Young and S. Robertson).

But, as I have mentioned before, in recent years I started to find myself in peculiar situations (to be described a bit later) that led me to the following observations:

• Project management, project portfolio management and requirements engineering (project scope definition) are strongly interrelated and while it has so far been acceptable to study and develop them separately at the academic level, implementation of either one of these methodologies in the real world will require any organization to seriously consider the other two as well.
• The business requirements elicitation (i.e. the initial phase of project scope definition) is underdeveloped (for good reasons to be explained later) in today’s project management science. Two notable exceptions are IT and software development, where project scope definition, aka business analysis, is relatively well-developed but somewhat “distanced” from the project manager’s domain of responsibilities
• Most of the companies rarely have a good grasp of all of the above-mentioned fields and the understanding of the interdependence between the three disciplines.
• While there is a multitude of great books devoted to each one of the aforementioned fields, there is a distinct lack of works dedicated to unifying project management, portfolio management and requirements engineering into one easily understood, user-friendly “best practices” platform.

Exhibit 1

Is It All Really Interconnected?

As promised, let me share some of the “confusing” experiences and conversations I have had in the course of my career that led me to suspect that project management, portfolio management and requirements engineering are somehow interconnected in the “real” world.

Project Management and Requirements Engineering

Example 1

Initially when teaching a project management course, both in corporate and university environments, I would eventually get to the project scope definition part of the course and say something to the effect of, “the project manager with the help of other technical team members and with input and the feedback from the customers shall define the project scope. Project scope is captured in the project plan or in a separate document called SRS (software requirements specifications), SOW (statement of work) or some other term depending on the industry you work in”

This statement was typically greeted by a complete silence in the room and about twenty pairs of eyes looking at me in utter confusion and bewilderment. Finally, the bravest student in the room would raise his hand and say something to the effect of, “This is all very informative, but how exactly do you do that?”

To address the gap I tried to use the great advances in requirements elicitation achieved in software development and transfer them to a two or three hour module on project scope definition in my course. The feedback from students exceeded all expectations! Many of them later claimed that project scope definition was their favourite part of the course. Some of the students, especially the ones from non-IT fields stated that they have never been exposed to this methodology. However, there still were a number of important topics that I did not have time to cover because I only had three-hour lecture at my disposal. Compare this to a typical two-day, sixteen hour “best practices” requirements engineering course.

Example 2

Another key overlap of project management and scope definition was best illustrated by a question asked by one of the business analysts attending my requirements engineering course, “OK, so what you are saying is that there is a project management triangle with scope, time and budget at the top of each corner. The project manager is in charge of time and budget and I am responsible for documenting the scope, since I am the only one qualified to gather and record the requirements. Let’s assume that we are capable of communicating really well back and forth about these three dimensions (which is rare). But what if we need to negotiate the triangle (i.e. different options) with the customer? Who should be doing that? How do we reconcile the fact that the project manager is in charge of the two dimensions and I am in charge of another?”

Project Management and Portfolio Management

Let me shift the focus to the higher levels of the organizational pyramid and describe several interesting interactions with senior managers of the companies I had the privilege to work with.

Example 3

The following conversation took place right after I finished presenting a project cost and budget estimation section to a group of executives of a large construction company.

Executive: “My department heads have always been telling me that we need more people to accomplish all of our projects. I have a bit of an issue with that stance since I don’t know whether:

1. They are lying to me and I just have to continue pressuring them to be more efficient and creative, or
2. They are telling the truth and I have to:
   1. Provide them with additional resources or
   2. Cut some projects

In addition, if I decide to pick 2b, how do I know which projects should be “killed”? And to complicate things even more, if I select 2a, what how do I convince a Board of Directors that increase in the headcount is a worthwhile investment?”

Me: “Well what we are discussing today is project management and your questions fall into the domain of portfolio management. I simply can’t answer those questions during a fifteen-minute break…

Executive: “I wish we had more time to talk about it”.

Example 4

Likewise, I was teaching a project portfolio management course to a group of high-ranking executives and as I was wrapping up the first module of the course, the following conversation between me and one of the managers in attendance took place:

Me: “And once you have selected the initial grouping of projects to include in your portfolio, you will have to manage them and monitor their performance.”

Manager: “Hey, wait a second, tracking and monitoring is in the domain of project management, isn’t it?”

Me: “Yes it is”

Manager: “So what you are saying is that unless I have reasonable level of project management, I can’t do this portfolio stuff?”

Me: “Unfortunately this would be very challenging. By the way you will also need a good grasp of scoping as well. Otherwise, how would you be able to make a “go/kill” decision on project proposals if you don’t know what you are trying to build?”

These conversations at one point reminded me of an infinite “rock-paper-scissors” game where one domain is dependent on the second knowledge area and the second one, in its turn, is correlated with the third methodology.

Applying the “Scientific” Approach

These instances of utter perplexity have led me to the re-examination of the classical portfolio management model (see Exhibit 2).

Exhibit 2

In a nutshell, this diagram demonstrates that in order to run a successful portfolio of projects the company has to start with an idea that should be encapsulated in a business case document. The document is submitted for a review (gate) and the management team makes a “go/kill” decision at that time. If the idea has received management’s blessing, the project charter is written and yet another review takes place. If the project is still considered to be valuable to the organization, the project charter is approved and the project moves to the planning stage, where the project plan is created, and to the execution phase with “go/kill” reviews at regular intervals. At each one of these reviews the following three questions have to be answered by the executives:

1. Will the project add value to the organization?
2. Has the desired portfolio balance been preserved?
3. Is this project still relevant to our strategy?

But here is a million-dollar question: what are the uniting characteristics of the first three steps in Exhibit 2, namely, creation of the business case, project charter and the project plan? In all of the first three steps someone has to scope the project and estimate the project with progressive degrees of accuracy as we move from the business case to the project plan. That is where requirements engineering and project management come into play!

In addition, once the project moves into the execution stage of the portfolio cycle, the organization needs a sound project management framework to control and monitor it to provide senior management with meaningful information for “go/kill” decisions at the later stages.

Let’s now examine the expanded, “zoomed-in” version of the above processes (see Exhibit 3).

As can be seen in Exhibit 3 once the idea for a new venture was generated, someone, typically the person responsible for the idea, has to write a business case document. The business case should enable the executives of the company to answer the three key project portfolio management questions mentioned earlier in this article. But how can an executive assess the value (typically financial, since most of the companies are in business to make money) of the project without having at least a ballpark estimate of the project cost? And how can we arrive at the project cost if we do not know, again at least at the high level, what we are building? Therefore, it is obvious that in order to write the business case document, the author should be able to first, scope the project (at a very high level) and estimate the project (again, at a very high level).

Thus, by examining the upper part of Exhibit 3 one can see that we started in the portfolio management’s domain, shifted to the scope definition area, moved to project management and came back to portfolio management.

Examination of the next two cycles (i.e. the project charter and the project plan phases) indicates that these back-and-forth shifts occur with a noticeable frequency: portfolio management to scope definition to project management and back to portfolio management. The last cycle implies executing, monitoring and reporting on the project and passing on the results to the domain of portfolio management for “go/kill” decisions.

Do We Know How To Gather Business Requirements?

As I have mentioned earlier, the problem is that unfortunately none of the generic, non-industry specific project management textbooks I know of (including PMBOK) provide you with proper methodologies for project scope definition. These books tell you a lot about budgeting, scheduling and communications with a multitude of supporting tools and techniques, like PERT, network diagrams, fast-tracking, crashing, meeting minutes, etc., but when it comes to project scoping – you are on your own, buddy!

I posed the same question that was asked by my students to one of the more experienced colleagues at a project management conference once and he finally managed to shed some light on the topic, “Look, project scope definition is so different in, say, software development from scoping in construction that it would be very difficult to generalize and institutionalize that particular knowledge area.”

Exhibit 3

I have to say, we are, as far as I know, quite proficient at developing detailed scope documents that typically emerge at the end of the planning stage. Stacks of blueprints, bills of materials, detailed lists, design and architecture documents – we are apparently quite capable of producing those. But when it comes to the initial stages of the projects, the elicitation of high-level initial set of customer problems, issues, needs and proposal of potential solutions – there is no universal framework that would allow us to accomplish this.

Do Companies Need Help?

American researchers employed by the Project Management Institute found out (based on the data released by the Bureau of Economic Analysis) that in 2001 the US public and private sectors combined spend approximately $2.3 trillion on projects every year. This number accounts for a quarter of United States’ GDP. If you care to extrapolate this number to the global level, you will arrive at a staggering number of $10 trillion worldwide being spent on projects in 2001.

Despite this grandiose shift in the nature of the work we do, Standish Group in its Chaos Report asserts that only 35% of the projects started in 2006 could be considered a success, meaning they were completed on time, on budget and met user requirements. Nineteen percent of projects were outright failures and the remaining 46% constituted troubled projects.

Furthermore, according to Standish Group five out of the eight top reasons why projects fail are related to requirements. They include:

• Incomplete requirements
• Lack of user involvement
• Unrealistic customer expectations
• Changing requirements and specifications
• Customers no longer need the features provided

On the project portfolio management side, Robert Cooper in his book “Portfolio Management For New Products: Second Edition” claims that:

• 84% of companies either do not conduct business cases for their projects or perform them on select key projects
• 89% of companies are flying blind with no metrics in place except for financial data
• 84% of companies are unable to adjust and realign their budgets with their business needs

Based on these facts Cooper asserts that out of the $2.3 trillion we spend annually on projects, $1 trillion ends up in underperforming projects.

I think the statistics shown in this section clearly demonstrate that we are a long way from perfection when it comes to selection, scoping and managing of our projects.

Conclusion

Based on the above examples and discussions, is it possible that our problems with projects are rooted in our inability to understand all three of the above-mentioned fields and, more importantly, our failure to appreciate their interdependence?

It appears to me that the answer to this question is a resounding “yes”. It can be seen from our practical, hands-on experiences; from the analysis of the theoretical project portfolio management model and, especially, from the project success and failure statistics available to us.

Good luck with your projects!

[¹] Just to clarify, requirements engineering, although is considered to be a part of project scope definition, very frequently falls into the hands of business analysts in the IT and software development industries, architects in the construction industry and engineers in the technology sectors.

---

Jamal Moustafaev BBA, MBA, PMP, founded Thinktank Consulting in 2003 The company is an industry leader in providing management consulting services to North American software development companies and IT shops. For further information, contact Jamal Moustafaev BBA, MBA, PMP President and CEO of Thinktank Consulting Inc. He can be reached at778-995-4396; [email protected]; or visit www.thinktankconsulting.ca