Introduction

In my consulting and training engagements I frequently get to have interesting discussions with executives and senior managers from around the world. Obviously, considering the nature of my professional domain, the conversations we have regularly revolve around the topic of project portfolio management. They ask me very interesting and difficult questions, and I have to provide them with clear and succinct answers.

After several years of doing this, I suddenly noticed that no matter what industry the company belongs to, of where (geographically) the conversation takes place, I always end up answering the same questions over and over again.

So I decided to come up with a series of articles "The CEO's Guide to Project Portfolio Management - Frequently Asked Questions Answered" that will span across several posts.

P.S. If there are any people out there who want to submit their own PPM-related questions, do not hesitate contacting me by leaving a comment here or sending an e-mail to info@thinktankconsulting.ca

Question #1 - What is Project Portfolio Management?

One of my favorite definitions of project portfolio management states the following:

Project portfolio management is the management of the organization’s projects so as to maximize the contribution of projects to the overall welfare and success of the enterprise subject to internal and external constraints by maximizing the project value, balancing the portfolio and aligning it with overall company strategy.

Introduction

The company to be discussed in this article is one of the largest oil and gas producers in the world. In this particular case we will examine the portfolio management system designed by one of the organization's regional IT departments.

The situation at the company was such that all the major IT projects were undertaken by the company headquarters, while the local IT departments were responsible mainly for servicing the needs of the offshore platforms. The executives of the regional department felt under constant pressure as many of the projects proposed by them, were denied by the headquarters an, yet, they remained responsible for the safety, reliability and security of all the offshore operations.

As a result they felt that creation of a portfolio scoring model would help them with (a) prioritization of their project proposals and (b) demonstration of the importance of their initiatives to the executive managers at the headquarters.

Strategy

The overall company strategy has been developed at the organizational headquarters and consisted of approximately ten strategic initiatives. However the strategies directly related to the regional offices were:

• Safety and reliability of all the operations
• Fiscal responsibility
• Simpler and more standardized procedures

The Scoring Model

The scoring model created as a result of a one-day facilitated project portfolio management session is presented in Table 1.

Table 1

As can been seen it was a very unusual model when compared to other scoring matrices described in the book. One may call it a purely risk-based approach to project prioritization.

The model included the following variables:

“If you don’t know where you are going,

you’ll probably end upsome place else.”

Yogi Berra

Tip #1: Understand the Importance of Requirements

Five out of the top eight reasons why projects fail are related to scope definition, according to the Standish Group. These include:

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

Further analysis of causes of “bad” requirements yielded the following results (see Table 1).

Table 1

 A study conducted by Barry Boehm (one of the leading thinkers in the field of software development) involved an analysis of 63 software development projects in companies such as  IBM, GTE and TRW and determined the relative costs of fixing an error at various stages of the project.  Results from the study, demonstrate a phenomenal increase in the cost of a mistake from one dollar at the Initiation stage of the project to $40-$1,000 range at the Closeout (see Figure 1).

Figure 1

 While this information is based on the software development industry, this trend, to a certain extent, holds true for most other industries.

The scope problem is not rooted in our inability to come up with detailed blueprints, bills of materials or design and architecture documents. The predicament lies in the initial stages of the projects, when we need to elicit a high-level initial set of customer problems, issues and needs, and propose potential solutions.

Another absolutely crucial aspect of requirements elicitation that, in the author's opinion, requires a complete overhaul of one's brain. The problem here lies in the fact that sentences and expressions that would appear to be absolutely normal and acceptable by regular people, must be met with a due portion of skepticism and questioning by the project managers.

I always joke with my project management training attendees that by the end of the first day they will all be turned from "homo sapiens" into the "homo projectus" because they will undergo a psychological breakthrough and develop certain allergies in the course of the class that will be considered abnormal by the rest of their coworkers and family members. Let us look at some examples.

Unspecified Information - Does the phrase "we get sales reports" seem like a normal and acceptable thing to say? After all we do hear it all the time when we chat with executives, sales, marketing and business development people all the time.

Imagine now that you are in charge of developing a system that will among other things provide the business development department with sales reports.  A "normal" person upon hearing the phrase "we get sales reports" will probably just nod his or her head, write down something along the lines of "provide sales reports to the business development team" in her notebook and move on to the next questions.

"Home projectus" on the other hand will (and should) explode with the following questions upon hearing that statement (see Table 1).

Table 1 - Unspecified Information

We ask these questions because we need to know:

• Who specifically will be getting these reports
• How and in what format will these reports be transferred to the readers
• What constitutes a sales report and how many types of reports exist

The readers of this article are encouraged to examine Tables 2 and 3 for some further examples - by the way all taken out of real project management documents - of unspecified comparisons and generalizations.

Table 2 - Unspecified Comparison 

Negotiation is a dialogue intended to produce an agreement

upon courses of action, not only by actively selling

your position but also by focusing on the other side's

interests, needs, priorities, constraints and perspective.

Tip #1: Use Investigative Negotiations

 When negotiating on projects, both parties involved default to the discussion of their respective demands or try to state their positions in the clearest ways possible. Dig into your own memories and try to see if you have ever heard the following statements from your clients or managers:

• “This project must be delivered by October 30^th of this year”.
• “You are limited to ten resources on this project”.

Project managers are also prone to uttering statements like:

• “We can’t hit this deadline even if we work sixteen hours a day”.
• “If I don’t get the resources I asked for, we are not going to deliver this project”.

The problem with this approach is that we focus on the positions or demands of both parties rather than trying to understand their underlying interests and reasons. We assume that the key to a successful negotiation lies in understanding what the counterpart actually wants. While this is true, it is not the end of the process but rather a beginning. Focusing on what their customers want frequently distracts even the most experienced project managers from why they want it in the first place.

Therefore, questions like "why?" and "why not?" become the project manager's best friends during any negotiation process.

Introduction

I have recently been contacted by one of my blog readers who asked me a very interesting question:

What are the estimation accuracy norms for different phases of the projects?

I found this question to be so interesting that I decided to dedicate my next posting to this particular topic. But in order to answer this question in full, let us start at the very beginning, the definition of the estimate itself.

The Definition of the Estimate

According to the Guide to the Project Management Body of Knowledge (PMBOK) published by the Project Management Institute the estimate is:

An assessment of the likely quantitative result.  Usually applied to project costs and durations and should always include some indication of accuracy (+/- x percent)

Think about this definition for a while ... If we are to believe the opinion of one of the leading project management institutions in the world, then a single number, say, "9 months", "$100,000" or "350 man-months", is not an estimate. However, statements like "9+/-3 months" or "$75,000 to $125,000" are indeed true estimates.

While this fact is well-known to any experienced project manager, many executives, sales, marketing and operations professionals are frequently very surprised when this piece of information is brought to their attention.

Let us try to explore some more and find the root causes of this phenomenon.

There is Uncertainty in the Estimation Process!

We must understand that there is almost always a serious degree of uncertainty in the estimation process. Here are just some of the questions that can never be answered at the very beginning of the project:

Introduction

The energy company to be analyzed in this section of the chapter is an Eastern European electrical company that has until recently enjoyed a full monopoly, selling the electricity at one fixed rate irrelevant of whether it was dealing with private residences, small, medium or large businesses or government agencies. However the recent legislation by the country's government allowed for the deregulation of the electricity market. This implied that any energy company from the three or four neighbouring countries would be able to enter the market and compete with the former monopolist when it came to selling electricity to both private residences and businesses.

In addition the company management felt that the value of the projects they have been delivering so far was too low. Also, the executives mentioned that they seemed to have too many initiatives on the go while utterly lacking the resources (primarily human) to deliver all of them on-time and on-budget.

Strategy

The company strategy has been well-defined before the project portfolio workshop and, considering the recent deregulation, consisted of the following elements:

• Need to design attractive products. This implies:
  
  • Various size of electricity packages
  • Fixed and variable rate packages to suit different customer needs
  • Extend loans to the customers needing them, especially the start-up businesses
  • Create different packages for households and businesses
• Increase revenues and profitability
• Improve public relations damaged by the years of monopolistic presence in the market
• Social responsibility - initiate more green programs

The Scoring Model

The scoring model developed during the facilitated portfolio management session contained the following variables (see Table 1):

• Strategic Fit
• Competitive Advantage
• Market Share Increase
• Time to break-even
• Resources
• Technical Complexity

Table 1

There is a multitude of potential problems that await the company without proper project portfolio management processes in place. Initially lack of portfolio management manifests in terms of reluctance to kill weak project proposals, project being selected based on politics or emotions and lack of strategic criteria in the project selection.

What are the immediate results of such ad-hoc approach? There are at least two: too many projects are added to the pipeline and many – if not the majority – of these ventures are of low-value to the organization.

These two aspects also have several long-term effects. Because the company resources are too thinly spread across multiple initiatives, delivery times tend to increase and the final quality of the products tends to suffer, because the employees are scrambling between multiple ventures, missing deadlines and making mistakes that are harder and harder to fix as the projects progress from initiation to the close-out stages.

The project failure rates increase either because the initial ideas were of poor value or because – even if they were indeed good ideas – the project teams fail to deliver quality products. As a result, the proverbial “product winners” that every executive craves to see in his company offerings are very hard to come by.

If one can use the sniper analogy, instead of placing few well-aimed shots from a high-quality rifle, the company fires multiple blasts from the shotgun hoping that some of the pellets fired will hit the targets.

Another interesting phenomenon that I have observed at multiple organizations is the accumulation of the technical debt that eventually eclipses all of the high-value project work the company can deliver instead.

Let me demonstrate this by a real-life example (see Figure 1). I once worked at an IT department of a large financial institution. The executive management of the department had a very interesting approach to their strategic planning; at the beginning of every year they would examine the previous year’s performance statistics and discover that the information technology group has delivered, say, fifty projects. They would go the strategic planning meeting of the entire company and claim something to the effect of:

A question that I get asked fairly frequently during my consulting or training engagements sounds something like this:

We have heard about this "project portfolio management methodology" ... How valuable is it and how do we go about implementing it?

Considering the number of times I had to answer this inquiry in the last four or five years, I decided that it might be a good idea to sum up at least the high-level steps required to implement PPM at any given company. And here is what it looks like:

Step 1: Executive Commitment

There should be a serious commitment from the senior executives of the company to install a systematic, formal and rigorous portfolio management process. The senior management must believe that companies that use PPM outperformed those who don’t.  For more information about the value of project portfolio management, see my earlier article "What is the Value of Project Portfolio Management?"

Step 2: Mature Project Management In-place

Successful implementation of project portfolio management would be severely challenged for organizations lacking   the ability to scope, estimate and manage its projects. Therefore the introduction of project portfolio management should start with a company getting a good grasp on project scoping and estimating, followed by project monitoring and control.

Step 3: Establish Your Throughput Capacity

Once the scoping, estimation and other project management processes have been implemented, the efforts of the organization should focus on the determination of throughput capacity of the project pipeline.

One of the easiest ways to assess pipeline capacity is to measure it in dollars or some other currency. For example, the company executives may decide that the total budget allocated to projects in the next calendar year will be $100 million. The budget for each successful project is then estimated and, depending on the allocation method used the projects will be added to specific buckets until all of the buckets are full.

Hi all,

I have had a chance to chat with Cornelius Fichtner of Project Management Podcast. We were discussing my new book "Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects" and in the course of the interview I was asked to answer the following questions:

1. What is project scope management?
2. What is the state of project scope management nowadays?
3. Why did you decide to write a book about it?
4. What makes this book unique?
5. Who is this book for?
6. What are the main processes in the project scope management?
7. What is the state of project scope management in the IT and software development industries?
8. What is the state of project scope management in construction, product development, engineering?
9. What is your perspective on project scope management in multidisciplinary or enterprise projects?
10. How does project management play into this?

I have already received some very positive feedback regarding the interview. Hope you enjoy it as well.

About the Author