Seven plus hours at the Frankfurt Airport before catching a flight home to Vancouver. Thank God for the Lufthansa Senator Lounge :)

On a more positive note, a very productive 2.5 months away from home: several troubled projects delivered on-time and on-budget and a lot of potential clients identified for my project and portfolio management training and consulting services.

Looking forward to the much-deserved time with my family!

 

 

My sincerest thanks to all the people who organized and attended my “How to Deliver Exceptional Project Results” seminar organized by the American chamber of Commerce in Baku, Azerbaijan. Some photos from this event for your viewing pleasure :)

 

 

Over my close to twenty years of project management consulting and training experience I have been involved in this discussion on more times than I care to remember. Some people claimed that as long as the project was completed on-time, on-budget and delivered a full scope promised, it should be considered a success.

Others claim that it is OK to be somewhat late and over budget, but deliver a great quality product. And yet there is another group of professionals that claims that – of course, within reason – budget and timeline are not that important as long as the project realizes the truly great idea behind it.

Let us try to analyze each one of the “project success” ingredients. Let us assume that we have a project at hand that has been completed on-time, on budget and delivered a full scope of excellent quality. Does this automatically imply that this was a successful project?

In order to assess this question, we would need to take a look at a couple of examples. Imagine that a real estate development company in 2014 commissioned a project manager and requested him to build a luxury condominium building near a local lake. The project manager has successfully completed the project on-time, on-budget and delivered the full scope requested. Having said that, shortly after the construction was finished, the executives discovered that due to a number of factors (including economic and demographic ones) they would be able to sell only 10% of the units built.

Can this project be considered a success? Most likely all of the readers will agree that it was not, since the company failed on the portfolio management end of the spectrum (i.e. selecting the projects with the highest possible business value).

Hi all,

Just wanted to give you a quick heads-up that I will be presenting at the American Chamber of Commerce of Azerbaijan on Thursday, September 18, 2014. The event titled “How to Deliver Exceptional Project Results” will take place in the Landmark 3 Building in Baku at 16:00.

Please contact member.service@amchamaz.org to book your place

 

Outline:

• Survey: Sounds Like Your Company?
  • Case Study: The “Virgin Lands” Fiasco
  • Some Modern Examples
  • Some Industry Statistics
• Formula: How to Deliver Good Projects?
• Overview of Project Portfolio Management
  • Three Pillars of The Portfolio Management
  • Project vs. Portfolio Management
• Project Management
  • How Are We Doing with Project Management?
  • Project Manager’s Responsibilities
  • Cost of Mistake
• Case Study: The British Navy in the “Age of Sail”
• Q&A

 

About Jamal Moustafaev:

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca

Through my years of hands-on project management work, consulting and training engagements I frequently noticed that project managers – or as I jokingly refer to them, “homo projectus” – at times have a very different perspective on things than “normal” people. So, below I took the liberty of documenting some of the situations where project manager’s psyche appears to be quite different from that of the human beings surrounding him.

 

1. Estimate is a range, not a single number – While many of us regard the notion of estimate fairly casually, freely using phrases like, “I think I will be done with this task in three hours”, or “I have budgeted $10,000 for the kitchen renovation project”, real project managers never provide single-number estimates due to inherent risks and uncertainties of any project. Instead they always provide their estimates in ranges.

   For example, a good project manager will say something to the effect of, “We think we can finish our home renovation in between two to three weeks”.
    

2. Estimates, Targets, Commitments – while these three words are frequently used as synonyms by the “normal” people, project managers know that there are distinct differences between these three terms. When they estimate, they usually answer questions like, “How much will it cost us to do Task A?”

   When they target, they attempt to provide the answers to questions like, “Can we build these features by 15-Nov-2015?” And finally commitment sounds like, “We are 90% sure that we can deliver this project in four months”
    

3. Estimates vs. Probabilities – unlike regular people good project managers know that these two concepts are strongly correlated. For example, when a resource says, “On average this task should take me five days to accomplish”, the project manager is usually the only person in the room who knows that the probability of finishing this task on-time is only 50% (see Figure 1).

So, who is the requirements analyst? He has to perform several roles at once. He has to be a translator, since he is responsible for capturing the requirements expressed in the language of the user or customer (typically a non-technical language) and translating it to the language understood by the technical project resources.

 

For example:

 

"The car must be really fast"

 

 converts to:

 

"The car shall be able to travel at a speed of up to 100 mph"

 

She has to be a keen observer, since she has to observe the work performed by the user from the user's rather than from the technical resource's perspective.

 

The requirements analyst has to be an interpreter of the work to be performed; in other words he should be able to reveal the essence of work, not its incarnation.

 

For example:

 

"The bottle opener must be rectangular in shape"

 

converts to:

 

"The bottle opener shall be able to open bottles with both round and rectangular necks"

 

Very frequently the requirements analyst is someone who invents better ways of performing the work described by the user.

 

For example:

 

“The dryer should have different drying cycles to accommodate for different types of loads”

 

converts to:

 

“The dryer shall have three different drying cycles (small, medium and large)”

and

“The dryer shall have a dryness sensor that will shut the device down once the laundry is completely dry”

 

Requirements analyst is also a scribe who should be able to record the results of her analysis in the form of stakeholder-understandable requirements specifications and analysis models that are necessary, verifiable, attainable, unambiguous, complete, consistent, traceable, concise and prioritized.

 

For example:

 

Despite the fact that the role of project manager has been “institutionalized” by many respected international organizations including the Project Management Institute (PMI) and the International Project Management Association (IPMA) there are still a lot of confusion associated with this profession.

In my consulting career I have encountered the following perceptions about the role of the project manager:

 

Project manager is not really a profession. Every technical person working for our company should have the skills required to manage projects. I should have the freedom to point to an accountant (developer, marketing analyst, engineer, designer, etc.) and say, “Mary, I am assigning this project to you!”

 

Project manager is really an administrative worker, whose job is to collect project updates from various team members, send e-mails, take meeting notes and maintain the project schedule in the project management software.

 

Project manager is a very senior member of the executive team who is responsible for both tactical (i.e. delivery on time and on budget) and strategic (delivering value to the organization) success of the project.

 

Let us take a look at the real responsibilities of the project manager (see Table 1) and then try to refute the statements above.

Project manager is assigned at the initiation stage of the project. This is a point of time when the “go” decision on the project has already been made by the senior management, who deemed that the project in question was a good idea and would most likely deliver the proverbial value to the company. Therefore the project manager (unless she combines the role of the project champion and the project manager) is not expected to be responsible for the strategic success of the project. She may ask the questions about the project value if she has strategic knowledge about the domain and if she is very brave, but in general, the CEO of a large international bank should not expect the project manager to challenge him on the strategic value of the “Payments System Replacement” endeavor.

I remember once attending a lecture at the project management conference. The topic of the seminar was “One Week in the Life of the University CIO” and the presenter has shared very interesting details about the daily challenges of the “chief IT guy” at one of the largest universities in North America. He started his talk with a screenshot of his weekly calendar taken from his MS Outlook software and used it to describe the issues encountered and solutions his team was able to find to address the said problems.

At one point of time he directed our attention to a rectangle in his schedule and explained that in that particular case he had to conduct a final interview with one of the candidates for the project manager job at the university. The CIO added something to the effect of, “We got lucky because we were able to find a person with a lot of technical experience with Oracle Database 12. He actually worked on a couple of similar projects as a systems architect.” When asked by one of the participants about the candidate’s project management pedigree, the CIO quipped, “He did not have any specific project management training or experience per se, but he participated as a team member on a number of technical projects”.

This was not by far the first time when I have encountered this approach to hiring of the project managers. Furthermore, I dare to predict that most of the readers of this article have come across a similar attitude exhibited by their senior managers. The essence of this approach can be summed up in the following format:

 

When selecting a project manager for my next project I would rather hire a candidate with strong technical skills in the domain and weak project management skills, rather than someone with little technical knowledge, but excellent project management skills.

 

On a side note I have seen also several extreme versions of this tactic when the recruiters told me that the employer was specifically looking for a person who has experience with version 9 of the platform (apparently knowledge of versions 8 or 10 just wouldn’t do).

Let us for a second assume that this is the right approach and examine a couple of very plausible scenarios that may happen at your organization.

Now that we have examined the pros and cons of the purely financial approach to portfolio let us turn our attention to a more balanced approach called the “scoring model”.

The essence of the scoring model approach is to come up with several variables that the executives consider important when assessing the value of their future projects. This is usually done during the project portfolio workshop where the instructor explains the theory behind the scoring approach, provides several examples of the scoring models developed by other companies and then asks the executives present to engage in a brainstorming exercise. The fundamental nature of this exercise is to generate as many relevant criteria as possible and record them on the whiteboard or a flipchart. These criteria may include, for example:

• Strategic alignment
• Market attractiveness
• Fit to existing supply chain
• Time to break-even
• NPV/ROI/IRR
• Product and competitive advantage
• Leverage of core competencies
• Technical Feasibility
• Risks, etc.

Once the discussion is over, the facilitator hands the red marker to the first person in the room and announces the following rules:

One of the most popular questions that frequently comes up in the conversations with senior and executive management of various companies is the one that appears in the title line of this article.

NOTE: This question, by the way, usually implies that the company has already taken a great leap forward and realized that it was impossible to accomplish all of their desired projects in a given period of time.

There are many different approaches to this task, but the most popular ones are the financial methods and the scoring models. Let us look first at the financial methodology. In a nutshell, it implies choosing some kind of a financial criterion – be it a return on investment, a net present value, an internal rate of return or some other formula – and calculating a value for each project. Once the ROI (or any other financial measure) for each project has been calculated, the projects are ranked according to their ROIs in the descending order.

Let us look at an example of how it may happen. We have a company that wants to implement 10 projects and has 200 man-months in their resource pool (roughly speaking 20 people working together for one year including the adjustments for the vacation time, sick days, etc.)

The list of projects together with their expected ROIs is presented in Table 1:

Table 1

Project	Estimated ROI
Project A	21%
Project B	5%
Project C	12%
Project D	3%