project management

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).

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.

A government of one of the countries in the Gulf region decided to embark on a project of building a multi-campus university in several - at times remote - locations. It was decreed that the said project should take five years to implement and the cost should be around US$200 million. It is not completely clear even after talking to several people actually involved in the endeavour right from the very beginning whether these constraints were just "dropped" from the very top of the government levels or if these were at least a very high-level estimates generated by a qualified party.

The scope of the project, at least at a very high level, was also thought to be well-understood. It included the following requirements:

• Engineering design of all five campuses (both conceptual and final)
• Construction of classrooms and lab training facilities
• Construction of dormitories
• Procurement and installation of all necessary equipment
• Setup of a new IT infrastructure including several data centers
• Design, development and delivery for over100 new courses,
• Setup and customization for a web e-learning portal

The primary contractor has decided to proceed with five different vendors to be responsible for different parts of the scope of the project. As a result, each vendor was requested to provide his version of the solution with respect to their vertical area of expertise. The primary contractor decided to simply aggregate individual scopes provided by the vendors into one united program scope. Consequently no thought was given to the proper integration between different scopes.

Finally, it turned out that the original RFP issued by the customer neglected to mention that the university will be constructed in an open desert with no water, electricity, sewage or roads. And since the primary contractor neglected to verify the existence (or absence, to be more precise) of all these ingredients, the budget and duration for the project mentioned in the original contract were, to say the least, inadequate.

The Story Of A2LL

A2LL – the German social services and unemployment software system was developed over the course of several years by T-Systems - a software department of state telecommunications company – along with ProSoz, a smaller company of about thirty developers located in the town of Herten.

The final product was delivered in the last quarter of 2004 and went live on January 1, 2005. The system consisted of the web browser front end, while the back end was based on 16 servers with 4 processors each.

Upon the deployment of the system at several large German cities including Cologne, Hamburg, Frankfurt and Berlin, the users at the welfare offices started reporting serious problems with the software.  Some of the problems encountered are listed in Exhibit 1.

 

Exhibit 1

System Bug Description	Type of Requirement
If data entered into the form was incomplete (e.g. someone missed one of the many questions) the system automatically deleted the record after about three or four weeks	Functional
Account numbers that were less than ten digits in length were filled with zeros at the end of the string rather than at the beginning (e.g. 3225223 became 3225223000 instead of 0003225223).	Functional
System was not capable of producing an “Analysis of Variance” report	Functional
System was not capable of producing a “Persons Who Received Too Much Money” report	Functional
System did not include the functionality to deal with the deductions for income from small jobs	Functional

Long time ago, when I was still working as a permanent employee, I was invited for a job interview by a local software product company. I arrived at their headquarters and was led to the conference room where I was greeted by the CEO, VP of Marketing and the CTO of the organization.

The interview went on without any surprises; I was asked to tell a little bit about myself, then the CEO told me about the current projects the company has been involved in lately, followed by the overview of the key products produced by the firm provided by the vice-president of marketing.

The CTO has been sitting quietly until that moment, but suddenly he shifted in his chair, looked at me somewhat intensely and the following conversation took place:

 

CTO: (looking at a copy of my resume) I see you don’t have any technical background …

Me: Well, I did work as a business analyst for a while, before taking on both the project management and requirements engineering roles at most of the companies I worked at.

CTO: That’s not what I meant. What I was trying to say is that you don’t have any coding experience.

Me: Oh, no … My educational background was in finance and management science.

CTO: How are you going to work with our developers then?

Me: I am sorry, I am not sure what you mean …

CTO: Well, you assign a task to the programmer and he tells you that it would take five days to accomplish it. How do you know he is not lying to you and it would take him only two days? He could spend the rest of his time on Facebook or YouTube …

 

I have to admit this was neither the first nor the last time I heard a variation of this argument in my project management career. Thus, I think it is time to make two very important points about this topic.