Tag: Requirements

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

With roots dating back fewer than 100 years, the project management discipline has evolved during one of the most spirited periods of innovation and technology advancement the world has seen. These days, work is underway worldwide bringing this applied science into its sharpest focus yet through the development of a new project management standard called ISO 21500.

Just as there are ISO (International Organization for Standardization) standards for organizational quality (ISO 9000) and environmental management (ISO 14000), when completed the new ISO 21500 standard will provide guidance and principles defining good practice in project management.

“To ensure openness and that the standard is globally accepted, ISO has solicited information from different countries, companies and individuals,” says Michael Kamel, chairman of the Canadian ISO 21500 Advisory Committee. The mammoth undertaking began some three years ago, when the British Standards Institute (BSI) approached the ISO about creating an international standard for project management. Currently, experts from 31 countries are involved, including Canada through the Standards Council of Canada. Five other countries are observing, while the Project Management Institute and International Project Management Association are among other major players.

“We have multiple ways of working together,” says Dr. Kamel, a professional engineer who is also president of the Project Management Institute’s Montreal chapter and manager of corporate strategy consulting at Deloitte. The process involves teams from each country producing components of the standard independently; country representatives meet periodically to discuss global and specific issues.

“One of the main challenges is the conversion of everyone to a common way of doing things,” says Dr. Kamel.

Unlike pure sciences such as physics, Dr. Kamel says project management is an applied science – one based heavily on practices and anecdotes of what works best. “It’s a grassroots discipline formalized initially by practitioners, rather than academics. But because it is newer than other management disciplines such as operations, there are not as many existing anecdotes.”

He says the work on ISO 21500 is building a solid base – a global framework – on which further anecdotal evidence on best practices may be built. “It will help us solidify our understanding of the best ways to do things under various project circumstances.”

Developing the standard is itself complex, but Dr. Kamel is confident the effort will be worthwhile. “With this standard, we will start to understand the world of complexities called management – and specifically project management,” he says.

The next milestone: constituents will meet in Japan this June to confer and continue the advancement of a standard that will eventually impact project management around the world.

This article originally appeared in a special information supplement on project management in The Globe and Mail on April 23, 2009.

Introduction

Factual and anecdotal evidence confirms that IT investments are inherently risky. On average, about 70% of all IT related projects fail to meet their on-time, on-budget objectives or to produce the expected business results. In one KPMG survey, 67% of the companies who participated said that their program/project management function was in need of improvement. Why? A number of leading factors for project failure were suggested by the survey, including the “usual suspects”: unreasonable project timelines, poorly defined requirements, poor scope management, and unclear project objectives. Granted, all of these factors can play a role in project success.


But are they the cause or project failure, or just a symptom of some larger issue? In this article, we will discuss that the root cause for many of these common failure points is really the ability to lead projects, not just manage them.

Leadership: Missing in Action

One would think that the proliferation of certified PMPs would have increased IT project success rates. However, given the research previously cited, this does not appear to be the case. Certainly, PMPs are cognizant of the processes, techniques and tools that should be used to manage projects and have documented project management experience. We contend that certification-the PMP-is indeed important, but that it alone is not sufficient for successful project management. Having been called on to rescue and turnaround numerous IT projects, we have had the opportunity to analyze why a project gets in trouble. As we looked at several of these troubled projects we realized that there appears to be a common link: leadership is missing in action. That is, while the project manager may be focused on what needs to be done and may well know how to do it, he or she may not be acting as a project leader. While certification is a good foundation for knowing what to do, it takes true leadership to drive complex projects to successful conclusions.

The PMI Body of Knowledge specifies five process groups for project management: Initiating, Planning, Executing, Controlling and Monitoring, and Closing. These five areas are consistent with the functions of management within an organization. Managers are responsible for planning, organizing, directing, resourcing, and controlling for the purpose of achieving organizational goals. The certified project manager should be able to demonstrate competent management of the nine PMI knowledge areas: project integration, scope, time, quality, cost, human resources, communications, risks, and procurement.

However, the ability to manage each of these project areas still may not produce successful project outcomes. Our experience on client sites for both government and commercial clients reveals that project leadership, not just management, is the critical differentiator. Project management without project leadership is likely to result in project failure.

Certainly, it is not our intent to redefine leadership. It’s already been defined as the ability to affect human behavior to accomplish a mission or the act of influencing a people to set and achieve goals. Volumes of business and strategy texts have been written about this critical competency. Check out your local book store and you will see numerous titles identifying leadership styles, leadership characteristics, and inspirational leadership topics. Some authors or practitioners have made the point that leadership and management represent two different skill sets and that either an individual has the characteristics and skills necessary for leadership or those more appropriate for management. Others have suggested that leadership is knowing where to go and that management is all about how to actually get there. We find this dichotomy troubling and perhaps at the heart of our IT project management failure rate. Instead, we believe that not only can project managers act as leaders, but in fact that they must provide leadership if projects are to achieve results.

A Closer Look at Project Leadership

Project leadership is all about shaping a team of diverse individuals (employers and contractors, some from different organizations) into a force that produces measurable project results. At our company, we recruit and develop project managers who can provide the leadership that complex IT projects require. At a basic level, project managers must be able to set the vision, define success, and determine the measurements of success. Then they must inspire, persuade, and lead the project team.

We argue that for project managers to become project leaders, they must demonstrate competence in essential skill areas. Successful project leadership involves:

• Leading courageously
• Influencing others
• Acting with resilience

Leading courageously is a critical competency because large IT projects have a huge resource pool representing different organizations and job roles. These resources may see their tasks slightly differently and may not all be aligned with project goals. Furthermore, the sheer number of issues and risks may make it difficult to zero in on those tasks that are most critical. In this kind of environment, leading courageously can easily make the difference between success and failure. Leading courageously means clarifying what is important and taking a stand to resolve important issues. It also requires driving hard on the right issues and confronting problems promptly. Finally, courageous project leadership means being decisive and challenging others to make tough choices.

Influencing others is an essential competency for most projects, but especially for those with large project teams, numerous stakeholders, and different user communities. Influencing others means giving compelling reasons for ideas and suggestions and winning support from others, both within the project team and in the user and stakeholder community. It also requires the ability to negotiate persuasively and get others to take action. Finally, it means influencing the decisions of upper management, whether within your own organization or the client organization.

Acting with resilience is critical to project leadership and is especially important when projects are at critical stages or in trouble. When a project manager acts with resilience, he or she keeps the focus on project goals and refuses to give up. Sometimes it means being tough enough, in the face of adversity, to fight the good fight and get agreement on issues that threaten to derail the project. Or it may simply require being flexible enough to negotiate solutions that keep driving for the goal of project success, when others might give up and accept defeat.

Summing It Up

In this article we’ve presented the case that project leadership is the differentiating factor in project success, especially on large, mission-critical projects. Knowing what to do and being able to manage the nine knowledge areas identified by PMI is not enough on complex projects.

Successful project managers must lead courageously and be able to influence others to resolve some of the most critical problems that projects experience. And to paraphrase Churchill, they must never, ever give up; they must act with resilience even in the face of conflict and problems. To experience the project success that investments demand, assign project managers who can act as project leaders to your mission-critical IT projects.

Dr. Karen McGraw is the founder, Chief Knowledge Officer, and past president of Cognitive Technologies. Dr. McGraw has extensive experience in technology-based performance improvement solutions ranging from the design and implementation of computer-based learning and learning management systems, to expert systems, performance support systems, intelligent interfaces, and knowledge management systems. Dr. McGraw is a co-developer of the Performance DNA toolkit for analyzing human performance to diagnose improvement opportunities. Dr. McGraw is nationally recognized in eLearning, knowledge acquisition, scenario-based requirements, and performance analysis and design and has authored five texts, including User-Centered Requirements and Knowledge Acquisition: Principles and Guidelines.