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.

Hi all,

I will be departing to Europe to run a couple of initiatives for one of the largest multinational oil and gas companies. Thinktank Consulting has been commissioned to take on two - and possibly more – of their troubled projects.

As a result, I will be away from Vancouver for a couple of months, but should be fully available via Skype (jmoustafaev) or e-mail (jmoustafaev@shaw.ca). Feel free to contact me if you have any questions or would like to discuss how I can help you with your project and portfolio management initiatives.

Cheers,

Jamal Moustafaev, MBA, PMP

About the Author

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

• Please follow me on Twitter: 
• Like our page on Facebook: 
• Connect with me on LinkedIn: 
• Subscribe to my RSS feed: 

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.

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

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.

This is a seemingly simple question, at least, for a certified project manager. After all we all know that a project is an “endeavor that has a definite start and an end, undertaken to deliver a unique product a service”. Usually this definition is followed by a couple of illustrative examples:

• Creation of the first prototype of the Formula One car is a project since it does have a defined start, an end and produces a unique product.
• Mass production of, say, canned soup is not a project, since while it has a defined start it does not have a defined end. Also, thousands of cans can’t be considered a unique product since all of them are identical.

These examples unfortunately do not reflect the complexities that are usually encountered when deploying project management at various organizations. I remember a consulting engagement when we were working together with a focus group of the employees at a large government organization. One of the tasks on our agenda was to determine what would be considered a project by the company standards and thus require the application of the project management methodology. The following conversation took place between one of the employees and me:

Me: Project is an endeavor that has a definite start and an end undertaken to deliver a unique product a service.

Employee: Wait a second! So, according to this definition the act of sending an e-mail is a project, right? It has a defined start and an end and represents a unique product …

Me: Well, you can look at it this way …

Employee: Does this mean I have to write a project charter, requirements document and a project plan every time I intend to create an email?

I once had a conversation with a CEO of relatively recent start up. At the moment our conversation took place the company existed for about six or seven years. The CEO mentioned how successful his organization was and how they were discussing plans about expanding their product portfolio into new fields including taking on very large and complex government-sponsored projects.

When I asked him whether he was planning to beef up the project management skills of his employees he looked at me inquisitively and quipped,

“You really think we need to do that? We have accumulated a pool of very talented technical people and I am fairly confident they can take on any challenge that comes along”.

This is by far not the first time I hear a variation of this statement. Many executives continue to believe that the gift of their employees to successfully tackle smaller projects will automatically transfer into the ability to take on larger strategic endeavours.

Every company that manages to survive the start up stage eventually reaches the point when sound project management and portfolio management become strategic assets for the organization. There is practically no way to pinpoint this spot; personal experience tells me that the company usually enters the “danger zone” when it reaches one hundred employees or its revenues exceed $10 million (depending on the country).

Why does it happen? Let us look at the situation from a purely economic perspective. One of the first basic assumptions of every economic model is that people are greedy. Here is a simple example: if I offer you to choose between two piles of money and one of them has one thousand dollars and another one – five thousand, which one would you choose?

Executives and especially the company owners are no different from normal human beings from this point of view. Thus, when a CEO whose company has been involved with projects measuring in tens of thousands of dollars, gets an opportunity to obtain a million-dollar project contract, he usually does not hesitate about whether his company is ready to take on that challenge. As a matter of fact, such events are usually a cause for great celebrations at the organizations worldwide.

I get asked this question all the time. My consulting engagements start with it. My trainings – whether public or on-site – start with it. Sometimes, I even hear it during casual conversations with my friends. Usually this inquiry is followed by the following statement, “Well, you are the project management expert! Care to share your opinion on the subject?”

In reality the answer to this question is not that simple and exists in a two-dimensional space, so to speak.

First, if the company is experiencing these problems, there is a good chance that their project management processes are deficient. The word “deficient” in this context can mean a number of things: lack of proper methodology and templates, absence of experienced project managers or insufficient executive buy-in for project management just to name a few. Any combination of these factors severely limits the ability of the organization to scope, estimate, schedule and control their endeavors potentially leading to missed deadlines, overrun budgets and poor quality products and services.

But there is also an additional dimension to this problem called the strategic resourcing. The question that needs to be answered in order to solve the strategic resourcing predicament is very simple:

“Do you have too many projects in the pipeline and too few resources at your disposal? And if the answer is yes, then which projects are you going to cut or how many resources are you going to add to your pool?”

Let me demonstrate this concept using a seeming unrelated example.

Let us assume that you are a student in one of my project management courses. You are an A+ scholar that knows everything there is to know about project management. To make a long story short, there is no question I can ask that you would be unable to answer.

Let us further assume that the average number of questions on a two-hour final exam for this type course is five. How well would you realistically expect to do on the two-hour exam if I were to decide to include a hundred questions of the same size and complexity on the final test? 

NOTE: Click here to download the full version of the "Airport Check-In Kiosk Software" Project Charter in the MS Word format.

Project "Airport Check-In Kiosk Software"

Problem/Opportunity Statements

O:  Divert the customer traffic away from check in attendants, thus reducing the costs

O: Better quality of service - higher availability

O: Faster passenger processing

Objectives

ABC Software Systems  shall study, configure and implement the Airport Check-In Kiosk software system for  XYZ Airlines by September of 2010. The project scope shall consist of the following features:

Table 1

NOTE: ABC Software is responsible for the delivery of the check-in software; actual kiosk hardware shall be procured, designed and delivered independently by XYZ Airlines and its vendors.

ROM Budget and Schedule

Budget - $100,000 +/- 50,000

Timeline - 6 +/- 2 months

Just spoke to my publisher at the CRC Press. It looks like my new book “Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects” will be released in October of 2014.

The book page can be accessed here.

I will keep your posted regarding the updates.

P.S. The cover picture you see in this release has not been approved yet. Hopefully very soon I will obtain several cover versions produced by my publisher and we can vote on the best option. Looking forward to your feedback!

I remember a conversation I once had with a Chief Operations Officer (COO) of a federal government agency involved in several megaprojects, i.e. the projects with budgets exceeding $1 billion. The situation at the organization was really bad: enormous budget overruns, missed milestones and unhappy stakeholders.

The following exchange took place between us:

Me: I heard about your challenges and your CEO has requested that I come in and help you with establishing proper project management processes …

COO: Yes, I know. We do have serious problems with our projects. But I just don’t get it; after all we have MS Project software installed on every desktop in this office! Even receptionists have it!

Me: You know what? You better come to my project management training too, at least, to the first module …

But all joking aside, I have been asked this question on pretty much every consulting engagement of mine:

Can we address our project (portfolio) management deficiencies by installing appropriate software?

The short and not very diplomatic answer to this question is unequivocal NO. And here is why:

Imagine that you can’t play a piano. As a matter of fact, you know nothing about music. Will the purchase of the best piano in the world address your inability to play? Probably not …

Another, more technical example. Imagine that you know nothing about accounting to the point that you can’t tell the difference between the debit and the credit. Will the installation of the most advanced accounting software on your desktop or laptop instantaneously make an accounting expert out of you?