Author: Jamal Moustafaev

“My Projects are Constantly Late, Over Budget and Deliver Low-Quality Products. What Can I Do?”

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 thestrategic 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? 

Obviously, no matter how smart and well-prepared you were for the exam, you would no doubt fail.

Interestingly enough, when professionals and, especially, executives are provided with the “final exam” case study, they unanimously agree that there is absolutely no chance that any student in the classroom would be able to answer all 100 questions in the course of two hours. But as soon as the concepts of “questions” and “final exam” are replaced with “projects” and “fiscal year” respectively their attitude changes completely and they start thinking something along the lines of, “Well if I somehow make them work a bit harder …”

The lesson here is a company must have an appreciation of its own throughput capacity and ensure that the total size of its ventures corresponds to the size of its project pipeline – meaning the number of projects your employees can handle and deliver successfully is a finite number, which falls under the project portfolio management domain.

So what is the conclusive answer to the question mentioned in the title of this article? If you organization is experiencing project delivery challenges, the root causes of this situation are most likely concealed in both inadequate project management and project portfolio management.

Don’t forget to leave your comments below.

Additional Items and Next Steps

This is a continuation of Implementing Project Management at a Functional Organization. At the conclusion of the first phase of our work, a list of action items was given to the company based on the issues identified in the first stage.  If you wish to reference the first part of this article, which appeared on May 5, 2010, please click here.

We also strongly recommended to the company’s management that they try to capture the “before” organizational project performance metrics with respect to time, budget, scope and stakeholder satisfaction. This data will be required in order to compare the results of the pilot project and decide whether it is beneficial for the company to move ahead to the next step in the project management framework initiative.

Further, it will be necessary to consider an efficient way of communicating project results (Phase 1 and all subsequent phases) to the entire company at each key milestone of the entire program. To this end, we proposed the creation of a “Project Management Framework” page on the company Intranet.

Figure 2

Phase 1	Phase 2	Phase 3
Introduce project management methodology (v1.0)	Revise and update project management methodology (v2.0)	Revise and update project management methodology (v3.0)
Introduce project management documentation (v1.0)	Revise and update project management documentation (v2.0)	Revise and update project management documentation (v3.0)
Conduct company-wide project management workshop	Determine the need for further training	Implement additional project management training
Commit to Strategic Project Manager (one pilot project)	Introduce Strategic Project Manager (one pilot project)	Introduce Strategic Project Managers (several pilot projects)
	Review the results of the pilot. Go/No go decision w.r.t. several pilot projects	Review the results of the pilot. Go/No go decision w.r.t. all strategic projects
	Determine on which projects the project management methodology is now mandatory
	Develop strategic program management/strategic resource management implementation plan	Introduce project portfolio management (PPM) and develop a PPM implementation plan

Figure 3

Note: Figures 4 to 7 demonstrate the linkage between the issues voiced by the company’s employees during the assessment stage of the project and the solutions proposed.

Proposal	Addresses which Issues	Explanation
Project Management Methodology	Lack of communications	Entire methodology is based on creation of proper documentation and peer reviews with the project stakeholders
	Lack of project management methodology	Self-explanatory
	Lack of accountability	Introduces Status Reports, Meeting Minutes and Lessons Learned documents
	Lack of project feasibility/ justification analysis	One of the sections of the Project Charter deals with project feasibility/justification

Figure 4

Proposal	Addresses Which Issues	Explanation
Project Management Documentation	Lack of communications	All documents address this issue
	Lack of project management methodology	All documents address this issue
	Lack of accountability	Status Reports, Project Charter and Project Plan
	Lack of project feasibility/justification analysis	Section of the Project Charter directly deals with project/ feasibility/justification

Figure 5

Proposal	Addresses Which Issues	Explanation
Project Management Workshop	Lack of communications	Workshop included a module dedicated to effective project communications and overview of all project management documents
	Lack of proper estimation	Entire workshop module was dedicated to generation, presentation and negotiation of estimates
	Lack of project management methodology	Workshop is dedicated to dissemination of project management skills and concepts
	Lack of project feasibility/justification analysis	Workshop included a discussion of project feasibility

Figure 6

Proposal	Addresses Which Issues	Explanation
Project Manager of Strategic Projects (Department-Independent)	Lack of interdepartmental communications	PM will be responsible for production and dissemination of all project-related documentation and conducting peer reviews across all the departments involved in the projects
	Lack of uniformity in project management approach	He/she will be responsible for maintaining all project documentation and following the methodology prescribed on an entire project rather than only parts of it
	Lack of accountability	Project Manager – Strategic Projects will be the person responsible for creation of Status Reports (accountability to project)
	Lack of project feasibility/justification analysis	He/she should be qualified to understand the basics of finance and be able to properly assess projects proposed
	Problem of underestimation	Project Manager – Strategic Projects should be properly trained to estimate projects with appropriate degree of accuracy
	Projects are frequently over the budget or late	Experienced project manager should be able to address this issue by using proper methodology, effective communications and improved project accountability

Figure 7

Implementation

Follow up

The following steps were undertaken as a result of the above-mentioned recommendations:

1. The project management methodology proposed (see Figure 2) was validated by the focus group and approved by the senior management. There was mutual agreement that the current methodology is only the first step in developing a company-specific project management framework and will be revised and updated in each of subsequent phases.
2. Six key project management documents (see Figure 2) were reviewed by the focus group and updated according to their feedback to better reflect the organization’s realities and specifics. These documents will also be updated in the following phases based on the feedback provided by the pilot project team members.
3. All of the people involved in projects (as project managers, team members, champions or any other types of stakeholders) have undergone a two-day project management seminar in order to familiarize them with key basics of project management.
4. Four pilot strategic projects were selected and department independent project managers (i.e. reporting to the Director of Project Management) were hired and assigned to manage them.
5. The project management department, with the assistance of the IT department, has created a “Project Management” section on the company Intranet where all the methodology documents and pilot project information are posted.

Lessons Learned

There were several lessons that we learned during the implementation of this initiative. Among them were:

1. Never try to impose an “off-the-shelf” project management methodology onto a functional (traditional) organization. Instead:
   • Interview a cross-section of company employees and, if possible customers and suppliers, to obtain the real project-related issues.
   • Use a “best practices” project management methodology to tailor the solutions proposed to the concerns voiced by the people working for the organization
2. Debrief key stakeholders at every milestone. Presentation software like PowerPoint with charts, graphs and tables is your best friend!
3. Initially try to concentrate on the simplest forms of the methodology. If processes and documents become too complicated people will find creative ways to ignore them!
4. Always use “focus groups” of company employees with at least a basic knowledge of project management to validate the processes and templates you are proposing. This will ensure that they are properly fine-tuned to company realities and you get buy-in.
5. Try to determine what constitutes a project and what doesn’t for that particular organization. Establish a threshold to distinguish between “project” and “business as usual”.
6. Run several one- or two-day company-wide project management seminars. Your mission is not to create several dozen project managers “overnight” but rather to familiarize all of the potential project stakeholders with the key concepts of project management.
7. If a significant resistance to change is encountered (a very likely scenario) try to apply a phased approach. For example, select a group of pilot projects to be run under the new methodology to be followed by all flagship projects, to be followed by all projects.
8. Introduce the role of a full-time project manager to the company. Depending on the number of pilot projects, the organization will probably require more than one.
9. Capturing the “before and after” project related data is essential. Otherwise it would be very difficult to prove to the naysayers (and the executives) that the project performance and results have indeed improved and that the investment has been worth the effort.
10. And finally, keep in mind that communication is the key. An intranet webpage dedicated to the new methodology and project-related news, seminars, debriefing lunch-and-learns, short updates during functional department head meetings – any combination of the above-mentioned tools should be used to carry the positive message to your organization.

---

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev also offers the following corporate seminars through his company:

“Practical Portfolio Management – Selecting & Managing The Right Projects”
“Successful Hands-On Management of IT and Software Projects” 
“Successful Hands-On Management of Modern-Day Projects” 
“From Waterfall to Agile – Practical Requirements Engineering”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

The Steppe Winds and the “Virgin Lands”

In 1953 after the death of a dictator Joseph Stalin, Nikita Khrushchev, the new Soviet leader became aware of the serious issues in the country’s agricultural sector. Because of the prolonged heavy investments in the industrial and military growth, coupled with a devastating war, the production of wheat, meat and dairy in Soviet Union had plummeted to historic levels. Russia, a traditional exporter of grain, was forced to buy it abroad.

Khrushchev, always an energetic and vigorous party leader, came up with what appeared to be a very creative solution to the grain shortage problem. He proposed to open up millions of acres of “virgin” land in the steppes of Kazakhstan north and east of the Aral Sea.

The overall aim of the “Virgin Lands Project” was to produce 20 million tons of grain by 1956. The project has begun with an army of 300,000 volunteers travelling by special trains to Northern Kazakhstan and Southern Siberia and erecting hundreds of tent cities. Another group of several hundred thousand students, soldiers and agricultural professionals joined them on a temporary basis until the first year’s harvest. In addition, 50,000 tractors and more than 6,000 trucks were moved to the area to assist the “project team” in preparing and ploughing the vast areas of land. As a result of these preparations in the first year of the programme, 190,000 km² were ploughed; in 1955, an extra 140,000 km² were ploughed.

The 1956 was a year of great success for the “Virgin Lands”; the original target of 20 million tons of wheat was more than tripled. Mr. Khrushchev and the rest of the country rejoiced. The original idea of investing billions of roubles into the steppes of Kazakhstan looked like a stroke of genius. Thick books were written and large canvases were painted describing the heroic efforts of the people. The project was a great success.

Unfortunately, around the end of 1956 major problems started to emerge amid all of the celebrations and festivities. First, it was discovered that the government was not prepared for a harvest of such proportions. Lack of storage barns and harvesting equipment led to immense losses. In addition, the Transportation Ministry had not reserved enough freight trains to move all of the grain to major cities. As a result the Soviet Union was forced to buy 20 million tonnes of grain from Canada to meet its needs and avoid famine. It was a humbling and humiliating experience for a country whose leadership was boasting that they could outpace US agricultural production.

The state had also discovered that the cost of Kazakh wheat was three times that of the grain grown in Ukraine, because of all the additional investments, increased demand for fertilizers and the need to support several hundred thousand workers in the middle of nowhere. Another reason was that there was only a 40% chance of favourable weather conditions in Kazakhstan in any given year. This fact was well-known to meteorologists and Khrushchev’s economic advisers, but they conveniently chose to ignore it.

And finally, the really horrendous effect of this endeavour was that the pioneers in 1954 while ploughing the thin fertile surface of the steppes had dug into the saline layer. As a result, in several years, due to lack of any measures to prevent erosion, much of that soil was simply blown away by the 95-mile-an-hour winds, covering many nearby towns with dirt and dust to a depth of up to six feet.

Let’s try to conduct an on-the-spot “lessons learned” exercise on this case study. If there ever was a project manager of the “Virgin Lands” endeavour, what mistakes and miscalculation did he make? The goal of the project in question as worded by the Soviet Gosplan (Ministry of Planning) was to “harvest 20 million tons of grain by ploughing at least 43 million hectares of ‘virgin lands’ in several areas of the country including Kazakhstan.” If we follow this definition, then the manager of the project, real or imaginary, did not commit any major mistakes; indeed 33 million hectares were ploughed and more than sixty million tons of wheat was harvested. Who can blame the project manager who had been told in no uncertain terms, “Take these resources, move them to Kazakh steppes, plough a lot of land and harvest even more grain”?

Subsequent transportation was the responsibility of other government bodies, namely the Ministry of Transportation. Calculation of economic feasibility of such venture was definitely not in the scope of project manager’s responsibilities, and finally, even if he had known about the ecological impact of his project, he wouldn’t have enough authority to go against Nikita Khrushchev.

In that case, who is to blame for this fiasco? Who should have forecasted the high cost of the final product? Who should have initiated several other parallel projects including silo building and preparations of additional freight trains? Who should have studied the historical meteorological data and drawn proper conclusions? Who should have foreseen the ecological impact of the “Virgin Land” project? Who should have assessed the overall value of the project; the balance of the auxiliary projects required to support the original one and calculated the strategic impacts?

In the context of the Soviet Union it was obviously the government, the, so to speak, executives of the country. However the purpose of this case study is not to lay blame on a specific group of people, but to ask a more interesting question:

“If these were not project management mistakes, what kind of mistakes were they?”

The answer to this question lies in the area of portfolio management – the art and science of assessment, selection and management of the projects in order to maximize their benefit to the organization.

The Story of Two Project Requests

To bring the portfolio management concept closer to home, let me share an event that happened to the author of this article not very long ago. I was working as a project management consultant for a very large retail company. One day I was approached by a representative of the accounting department and the following conversation took place between her (Accountant) and me (PM):

Accountant: “We have discovered a problem with our accounting system. Because of the glitch in the software a certain percentage of transactions is “lost”. These orphaned transactions have to be posted manually which requires a lot of time and effort. According to our estimates we lose approximately $60,000 annually on manual corrections. Can you help us with that?

PM: “Yes, we have been informed about this issue and have done some homework; it looks like a $50,000 project …”

Accountant: “Hmm … Unfortunately we have exhausted our budget for this year. I guess we will have to revisit this issue in the next quarter”

One the same day I was approached by a representative of the marketing department who also wanted to discuss a project idea.

Marketing Representative: “We need to update our website; we have a fairly long list of modifications to implement and need you to help us with that.”

PM: “OK, no problem. So, what is it that you want to change?”

Marketing Representative: “Well, we need to change bullets on this page from small black ones to larger red ones. Also, increase the font size from 9 to 11 and modify this area so we can insert photos here… (a very long list of purely cosmetic requirements follows).”

PM: “No problem, I think we can do it. If you don’t mind me asking, who uses this website?”

Marketing Representative: “It is a section of our company’s intranet. It is targeted at our store sales associates. They use this website to learn about updates in HR policy, read company news, etc.”

PM: “So, are there any direct financial benefits you expect to realize from this project? I have to warn you, the total cost of all these improvements will be around $50,000.”

Marketing Representative: “No benefits I can think of. We just have approximately $50,000 remaining in our budget and our director decided to improve this site.”

What happened in these two conversations that took place a couple of hours apart? Two project requests generated by different departments of the same company were presented and described. The first project with a very positive return on investment was rejected because the department in question did not have enough money in their budget. One does not need complicated financial formulas to understand that a deal involving $50,000 investment and resulting in $60,000 annual savings is a very lucrative venture.

The second project was a purely cosmetic uplift to an internal website infrequently used by the most junior members of the corporation. It was not expected to generate any additional financial or other benefits, whatsoever. If one takes off the “project manager’s hat” and puts on the “CEO’s hat”, what do these two stories tell you about the health of the company’s project portfolio mix? Obviously, that the $50,000 project estimate was negligible in comparison to the rest of the company’s portfolio. But still, if part of the vast machinery had malfunctioned, wasn’t it a symptom of much bigger problems?

The explanations of this situation as well as of the failure of Virgin Lands project lies in improper portfolio management – the art and science of selecting and managing the right projects for one’s company.

Some Statistics
Is improper or complete lack of project portfolio management an issue in today’s corporate world? Let’s revisit some of the statistics from article “Harnessing the Chaos; Are Portfolio, Project and Requirements Management Interrelated?“

• The Project Management Institute found out (based on the data released by the Bureau of Economic Analysis) in 2001, that the US public and private sectors combined spend approximately $2.3 trillion on projects every year.
• This number accounts for a quarter of the 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.
• 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
• End result? Close to $1 trillion in underperforming projects in US as of 2001 and $4 trillion worldwide

The numbers provided above clearly demonstrate that modern businesses are not exactly, what one would call, methodical or systematic when it comes to proper assessment and selection of their project mixes.

What Executives Want …

An executive I spoke with recently complained about the problems he associated with project management,

“You know, we implemented project management methodology at our organization several years ago. There are some improvements, obviously: projects are more controllable, most of them are on time and on budget and the quality has improved considerably. There is, however, something missing, something we hoped would be addressed by project management. Firstly, a considerable percentage of the products we deliver to the marketplace turned out to be not as successful as we expected them to be. In addition, my people still complain that they are overworked and project managers constantly demand more resources. We claim to be the market leader in innovation but I have recently discovered that only five percent of out projects can be qualified as R&D ventures … What are we doing wrong?”

A book I read recently contained another very interesting description of executives’ needs:

“Executives do not go to shareholder meetings and cocktail parties to brag about what a professional group of project managers their organization has. Their mission is to make more money or (in a non-profit organization) to achieve their specific goals”

Gone are the days when the presidents and vice presidents were interested in just two things about their organization’s projects: when will they be finished and what will they cost. Now, especially in the for-profit areas, they want to know if the mix of projects will maximize long-run growth and ROI for the firm, how these projects support strategic initiatives, and how they will affect the value of the company’s stock.

Project Portfolio Management Introduced

“The New Product” Case Study
Let us start this section with a discussion of the following completely fictional case study – an impromptu conversation between Bob, director of mobile devices and Michael, senior vice president of product development.

Michael: “What’s new in mobile phones?”

Bob: “Nothing much on our front; we are preparing for the release of our ‘Notebook’ product with advanced word editing, spreadsheet and e-mail capabilities. But I read in a press release that our competitor ‘Mokia’ is introducing a new cell phone with a 15-megapixel camera and 1,000 gigabyte storage for media files.”

Michael: “Oh my God! They have beaten us again! We can’t let this happen. I want you to concentrate on the improved camera and storage capabilities. There is an industry exhibit in January and I want us to showcase a product that will outperform their device. Get the design and engineering teams to work on it with you. This is a top priority from now on!”

Before moving on to the analysis of this case study, ask yourselves, how many times in your professional lives – irrelevant of what industry you are in – have you witnessed a situation similar to the one described above? How many times have you seen projects initiated based on the “on-the-spot” decision by your superior?

So, what mistakes (if any) were made by Michael in this story? Exhibit 1 lists some of the problematic areas in his decision to concentrate on camera and storage capabilities for the new cell phone.

Exhibit 1

Questions	Explanation
What is the opinion of the technical experts (engineers and marketing people)?	Is it technologically possible to build a mobile phone that would outperform the device with a 15-megapixel camera and 1,000 gigabyte storage? Is there a market for such device?
How important is this project to the goals of the company?	How would this project fit into the existing project mix of the company?
How well is it aligned with company strategy?	Company seems to be concentrating on the office communications mobile devices (involving word processors, spreadsheets, etc.); would the shift into entertainment-type cell phones be even feasible for them?
How good is the project?	What are the potential revenues of this venture? What would this project cost? Do we have enough in-house expertise with respect to entertainment-type mobile devices? Are there any risks associated with commercialization of the product in question? Can this project be finished on-time for the exhibition? Are there any other risks?
Where will the resources come from for the project?	Does the company have enough free resources to throw at this project?
What projects should be “bumped”?	If the resources are not currently available, what projects should be cancelled or postponed in order to provide resources for this one?

Project Portfolio Management Explained

Project Portfolio Management is defined as a methodology for analyzing, selecting and collectively managing a group of current or proposed projects based on numerous key characteristics, while honouring constraints imposed by management or external real-world factors.

The three key requirements that portfolio management professionals impose on every candidate are:

• Each project as well as the portfolio of projects should maximize the value for the company.
• The candidate project should preserve the desired balance in the portfolio mix
• The final portfolio of projects is strategically aligned and truly reflects the business’s strategy

The definition of “value” can vary from company to company and even from project to project but typically it includes certain economic measures (e.g. return on investment, net present value, and payback), competitive advantage, market attractiveness, expected sales, probability of success, etc.

The “balance requirement” ensures that the following situations are successfully avoided:

• Too many small projects and not enough breakthrough, visionary projects
• Too many short-term and not enough long-term strategic projects
• Certain business areas are receiving a disproportionate amount of resources
• Poor risk management (all eggs in one basket)

Finally, the “fit to the strategic goals” requirement makes certain that company finances and other resources are not wasted on ventures outside of the organization’s sphere of strategic interests. This particular topic of strategic blunders has been discussed in numerous strategic management textbooks: Harley Davidson deciding to create “Harley Davidson” perfumes, French pen-maker Bic producing women’s underwear, salty snack maker Frito Lay coming up with a “Frito Lay Lemonade” product and Xerox’s decision to move into the software business, to name a few.

Project Portfolio Management Process Overview

The project portfolio management process can be subdivided into two separate steps:

• Prioritization and selection of candidate projects for the portfolio
• Maintaining the pipeline: continuing, delaying or terminating approved projects

The first phase happens before project initiation and starts with a preparation of business cases and a subsequent evaluation of the projects’ values, benefits and risks that may modify the aforementioned benefits (see Exhibit 2). Then, the overall fit of each project in the organizational strategy is determined. Next, the overall balance of the project portfolio is examined in order to ensure that no department or direction has received insufficient or too much weight in the final portfolio.

Exhibit 2

 

Exhibit Definitions:

• PPM – project portfolio management
• PM – project management
• SM – scope management (aka scope definition)
• VHL – very high level
• HL – high level

The next step would be to rank all of the successful candidates according to their selections criteria and assess the overall company resources available for the next period. The resources start getting assigned to the projects on the list until all of the resources are exhausted.

The interesting aspect of the last two exercises is that the company management will need to assess the inventory of available resources (including human resources), decide on an optimum or acceptable size for the pipeline (while considering “Business As Usual” aspect) and estimate durations, costs and human resource requirements for each candidate project. Accomplishing these tasks without a sound project management and scope definition capabilities would be very challenging tasks indeed!

In a simplistic project portfolio management model, once the final selections have been made and the sequence of the projects established and properly aligned with company resources, the process moves into the second phase. In this phase, the project pipeline is maintained by traditional project initiation, execution, and control techniques as well as periodic reviews of each project with respect to the original three pillars of portfolio management:

• Value
• Balanced portfolio and
• Fit with the company’s strategic goals

The questions that should be asked at each review – especially at the end of project initiation and project planning stages – include:

• Is the original business case for the project with respect to value, balance and strategic fit still supported?
• Are there any drastic changes to the project budget, duration, revenue projections and any other factors considered at selection?
• What projects should be killed because they no longer fit the original criteria?
• What projects should be added to the mix because of the conditions, ideas and market demands?

Once the projects move into the execution phase the following questions get added to the mix (see Exhibit 3):

• Is the project on time?
• Is it on budget?
• What are the key milestones?
• What are the technical and design issues?

Exhibit 3

 

Exhibit Definitions

• PPM – project portfolio management
• PM – project management
• SM – scope management (aka scope definition)
• DL – detailed level

What Project Portfolio Management Isn’t

Project portfolio management frequently gets confused with enterprise project management, professional services automation, management of multiple projects and program management. It should be noted that all of the above are variances or expansions of the project management since they do not address the alignment of projects with strategies or the science of selecting the right projects.

Project vs. Portfolio Management: The “Typewriter Effect”
Let us also try to establish a boundary between project management and portfolio management. There is a group of activities sometimes – at least in my experience – attributed to project management responsibilities, but belong to a completely different group; Identifying needs and opportunities, deciding which projects should be undertaken and which ones should be killed, establishing project priorities, assessing revenue and cash flow projections, aligning project mix with organizational goals and balancing the project portfolio. All of these tasks fall into the portfolio management’s domain, which is typically the responsibility of the executives rather than project managers (see Exhibit 4).

Exhibit 4

I like to refer to this phenomenon as a “Typewriter Effect”. Imagine, that project manager Bob was hired by Company X and told to deliver the best model of the typewriter ever built. He may have questioned the financial feasibility of such venture, but was told in no uncertain terms to stop complaining and concentrate on the project. As a result, Bob has collected all of the requirements from appropriate stakeholders, built the project plan with schedule and resource requirements, managed the team properly and successfully delivered the product on time and on budget.

Once the product was shipped to stores, company management – to their great surprise – discovered that there were no line-ups and waiting lists of consumers anxious to buy it, because everybody has been using word processing software for the last twenty or so years.

Can we blame Bob for the product failure? Could he really continue insisting that the project was a bad idea? Would he be able to keep his job if he did that?

This example, albeit a bit unrealistic, clearly demonstrates the boundary between portfolio and project management. Whether the project is a good or bad idea should be decided in the portfolio management phase of the overall process, while the successful delivery is taken care of in the project management phase.

What Happens without Project Portfolio Management?

Sounds Like Your Company?
What happens if a company does not have sound portfolio management methodology in place? Some of the symptoms that the organization does not properly analyze, select and manage its projects are:

• Project and functional managers often fight over resources
• Priorities of projects frequently change, with resources reassigned
• Senior managers have authority to unilaterally approve and release projects
• Projects are started as soon as approved by senior managers, irrespective of the resource availability
• Senior management frequently complains about how long the projects take
• Even if the strategic idea is implemented, the company sometimes does not achieve the expected improvement
• There is no comprehensive document or portfolio that links all of the organization’s projects to the strategic plan
• There is a significant turnover at the senior management level, right up through the president
• The strategic plan is presented as a list of initiatives. The cause-effect logic tying those initiatives to the goals of the organization is absent
• The list of initiatives is not prioritized. Therefore, it is assumed that all ideas should be implemented simultaneously

There are 10 symptoms listed above. Out of curiosity, try to read through them once more and try to determine how many of them apply to the organization you are currently working for?

The Cause and Effect Matrix

The symptoms of lack of portfolio management, described above, unfortunately represent only half of the story. The end result is even more depressing (see Exhibit 4).

Reluctance to kill the projects and maintenance of an ever-widening tunnel rather than funnel of the project pipeline leads to chronic lack of resources, poor quality of product, missed deadlines and, most importantly, high commercial failure rates of the products or services created as a result of these projects.

A logical by-product of such an approach is the apparent lack of real “product winners” that capture the customers’ hearts and generate considerable revenues for companies.

Finally, if there are no strategic fit criteria present in the selection mix, a lot of the company’s projects may end up – and in the author’s experience they almost always do – being secondary, unimportant and wasteful ventures that do not benefit the organization.

Exhibit 5

What Is Needed For Project Portfolio Management?

The obvious question to ask at this point would be, “What kind of capabilities should an organization have in order to implement a successful portfolio management program?” As can be seen for the previous sections (see Exhibits 2 and 3) running proper portfolio management processes implies having well-developed and centralized project management capabilities in place, especially project scoping and estimation.

Exhibit 6

Scoping and estimation play an especially important role during the business case, project charter and project plan phases when the organization’s executives have to assess the economic feasibility and resource requirements of the proposed projects in order to come up with the prioritized project list (see Exhibit 6).

Also, there must be a desire to develop a structured approach to project selection going all the way to the upper echelons of the organization. Since the selection processes should be handled by the most senior people in the company, implementation of the portfolio management must be accompanied by their explicit approval and participation.

Finally, depending on how far the company is along the project management path, new support roles may need to be created. Finally, depending on how far the company is along the project management path, new support roles may need to be created

These may include, project and program managers, portfolio director, PMO roles, etc.

Summary

Most companies today are struggling when it comes to proper and systematic analysis, assessment and selection of the right projects.

Furthermore, the executives of many organizations are shifting their focus from tactical project management aspects of their ventures to more strategic, portfolio management facets of their entire project mix. Their interests lie more in the domain of the value of their portfolios, their proper balance and their alignment with organizational strategic goals.

Project Portfolio Management is a systemic approach to analyzing, selecting and collectively managing a company’s projects according to three key characteristics – project value, portfolio balance and alignment with strategy – while subject to resource, fiscal and other relevant constraints.

The portfolio management process consists of two sequential phases: selection and prioritization of candidate projects and maintaining the pipeline by continuing, delaying or terminating approved projects.

The absence of a systemic approach to portfolio management can result in high project failure rates, either technical or commercial, too few stellar product winners, increased times to market and wasted resources.

While project and portfolio management are two distinct domains, having established and centralized project management capabilities, especially project scoping and estimation, are paramount to a successful portfolio management methodology implementation.

Bibliography

1. “Project Management” by Robert Santarossa
2. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
3. “Portfolio Management for New Products” by Robert Cooper
4. “A Management Framework for Project, Program and Portfolio Integration” by Max Wideman
5. “Project Portfolio Management: A Practical Guide To Selecting Projects, Managing Portfolios and Maximizing Benefits” by Harvey Levine
6. “Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed” by Gerald Kendall and Steven Rollins
7. “IT Portfolio Management Step-By-Step: Unlocking the Business Value of Technology” by Bryan Maizlish and Robert Handler
8. “IT Project Portfolio Management” by Stephen Bonham
9. “The Program Management Office: Establishing, Managing and Growing the Value of a PMO” by Craig Letavec
10. “Best Practices in Product Innovation: What Distinguishes Top Performers” by Robert Cooper
11. “Brand Failures: The Truth About The 100 Biggest Branding Mistakes Of All Time” by Matt Haig
12. “Historical Blunders” (Paperback) by Geoffrey Regan

Don’t forget to leave your comments below

---

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev also offers the following corporate seminars through his company:

“Practical Portfolio Management – Selecting & Managing The Right Projects”
“Successful Hands-On Management of IT and Software Projects” 
“Successful Hands-On Management of Modern-Day Projects” 
“From Waterfall to Agile – Practical Requirements Engineering”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

The Camel is a Horse Designed by Committee

The French shipbuilders produced a curious quartet of battleships over the course of twelve years in the late nineteenth century – the Hoche and her sisters Marceau, Magenta and Neptune. It has been argued by some naval historians that because of the accumulation of various features, bits and pieces demanded by multiple departments, they eventually lost any resemblance to battleships.

A foreign critic described one of the ships as “a half-submerged whale with a number of laborer’s cottages built on its back.” A domestic columnist, while being understandably more sympathetic, referred to her as “Le Grand Hotel.”

During the 1880s, French shipbuilders for some inexplicable reasons decided to design their ships by uniting the scoping, design and building phases into one very confusing process. As a result Hoche and her sisters took a staggering 12 years to build while every new and “cool” naval development was added to the ships’ design regardless of its the compatibility with the original blueprint. As a result of such rampant scope creep the Magenta underwent the following transformations (see Exhibit 1):

Exhibit 1

Sequence of Changes	Description Of Changes
Initial design	Armament -three 13.4 inch guns Top speed – 14.5 knots Displacement – 9,800 tons
First change	Change armament from three 13.4 inch guns to two 13.4 inch guns and two 10.8 inch guns
Second change	Change armament from two 13.4 inch guns and two 10.8 inch guns to four 13.4 inch guns and no 10.8 inch guns
Third change	Lengthen and broaden the ship to increase its speed to 16 knots
Fourth change	Add massive military masts and armored conning tower
Fifth change	Add torpedo nets and searchlights
Sixth change	Add a battery of quick-firing guns

Consequently, when Magenta was completed in 1893, she was three hundred tons overweight and lost 30% of her planned stability. The”Conseils de Travaux, charged with overseeing the construction, was accused of behaving like medieval bishops building a Gothic cathedral and the ship itself was being compared to a “three-storied chateau” rising forty feet above the armored belt with sixty guns of different calibers. It was calculated that if the Magenta had trained all of her guns to one side, she would have capsized.

The final nail in the coffin so to speak was unpretentiously provided by the ship’s captain who claimed, “A ship may go into battle only once in its life, and for thirty years it will be inactive. The superstructures annoying in battle, will notably improve habitability for ordinary life.” No wonder the ship was dubbed “Le Grand Hotel”!

These unfortunate vessels were arguably the worst battleships in the French navy. Their service lives were not long. The Magenta was broken up in 1911 and the Hoche was sunk as a practice target on December 2^nd, 1913.

The lessons of this case study are fairly obvious: good project results can not be achieved if the project manager loses control over scope and fails to curb the expectations of the stakeholders.

The Importance of Scope Management

Scope management becomes one of the key activities once the project has entered the execution stage. I have had a lot of discussions with my colleagues and students alike, especially in recent times, regarding the appropriateness of the scope management process on various projects. Some of them complained that their customers have treated the scope management process with a certain degree of hostility and their management is convinced that the procedure contradicts the best practices of customer satisfaction. Yet others took the discussions further by asking a more appropriate question, “How extensive and formal should the change request procedures be for projects of varying size and complexity?”

While it is practically impossible to provide everyone with a universal framework that would fit the needs of any project, I tend to believe that the principles discussed in this article are applicable to all ventures, large and small, simple and sophisticated. The only difference would be the degree of formality associated with this methodology. On a small, simple endeavor, all the principles discussed below can remain at the verbal level with probably one summary e-mail exchanged between the parties. On the other hand, on a very complicated mega-project there would be a lot of documentation, formal meetings and sometimes sophisticated negotiations accompanying every change request.

Consequently, here we are targeting “somewhere-in-between” projects with an assumption that an experienced project manager would be able to fine-tune the degree of formality to the complexity of the project he is working on.

Managing Scope and Stakeholder Expectations: Why Manage Expectations?

One of the project scoping books I have read recently read contained a very interesting phrase, “The difference between disappointment and delight is not a matter of delivery but of how well delivery matches the client’s expectations.” Therefore, controlling customers’ expectations is one of the key success factors, especially once the project has left the planning stage behind and entered the execution phase.

There are several reasons behind the necessity to limit the stakeholders’ expectations. First, because no matter how good one is at capturing and documenting project scope, no matter how many times the team has inspected and peer reviewed the project documents, there will always be omissions, mistakes and errors. Since nobody on the project team is perfect, the customers should be psychologically ready to accept that certain imperfections will rear their heads as you progress through the execution stage. A straightforward communication of this simple fact should limit stakeholders’ expectations in a healthy way.

People in general – and the project customers in particular – are not always logical. To further illustrate this point, consider a time in your life when you or your significant other has saved a coupon from a hotel or restaurant chain to obtain a significant discount at the said business only to discover upon arrival that the coupon was valid only at participating outlets. All your protestations are put to rest by a polite clerk pointing out to a couple of lines printed in an almost invisible font at the very bottom of the document, “Valid only at participating businesses. Check with the specific branch before the trip.”

On one hand, especially from a legal standpoint, this situation is completely the customer’s fault. After all, he or she was expected to read the entire document and arrive at proper conclusions. On the other hand, however, did the chain do a particularly great job of managing customer’s expectations? Probably not, since it doesn’t take an experienced psychologist to know that the vast majority of people have a short attention span when it comes to marketing media and tends to ignore the small font at the bottom or on the reverse side of the coupons …

So remember that being logically or even legally correct is not the same as making the customers happy. Some of the project managers, including the author of this article like to include a section titled “Scope Exclusions” to the project management documents to explicitly state the features that will be excluded from the project scope. Needless to say, this section of the document is highly visible and created using the same font as the rest of the document.

People, especially if they are from different cultural backgrounds, different industries or even different departments of the same company, tend to perceive things differently. As a result, you may think that you and your counterpart are discussing a scope item using fairly similar language only to discover much later that you had been talking about two completely different things.

One of my favorite examples of differing perceptions is the story that took place during Lady Astor’s (one of the first British female politicians) election campaign in Plymouth some time around 1918-1919. According to the legend, Viscountess Astor was canvassing for her first parliamentary seat in the port city of Plymouth. Because of her status and because she was new in town, she was allotted a senior naval officer as her escort. At one point of time during their improvised campaign they approached one of the houses near the port and knocked on the door. A little girl opened the door and the following exchange took place:

Lady Astor: “Is your mother home?”
Little girl: “No, but she said if a lady comes with a sailor they are to use the upstairs room and leave ten bob”

On a more serious note, I once was working on a project to develop a CRM (customer relationship management) website for a resort booking call center. I was discussing the final details of the system with the Director of Customer Management, a young lady who was not very well-versed in the intricacies of software development. At one point I asked her about the desired system availability or uptime.

Director: “Oh, this is a very important system, so I expect it to operate at the highest availability possible. It should be available 100% of the time.”
Me: “Well, 100% availability is basically impossible, even the most complicated systems have to be maintained and upgraded once in a while.”

Director: “So, what is possible?”
Me: “Theoretically you can have 87%, 95% or 99.9% uptime …”

Director: “We only want the best! I shall choose 99.9%”
Me: “OK, but you do realize we will need $20-25 million for that? By the way why would you need that level of uptime? To put it in perspective 99.9% implies that the system will be off only for less than nine hours in a year”

Director: “Oh, I get it now … You misunderstood me, what I wanted is for the system to be up between 9:00 am and 5:00 pm on weekdays. We don’t care what happens to it outside of these times.”

What happened in our conversation? For me the “best possible availability” of the system meant 99.9% of uptime and multi-million expenses associated with it. Whereas for her “best possible availability” meant the system being available only during the working hours Monday to Friday. Had we not have this discussion, we could have encountered some issues later in the project.

What happens if the project manager decides at some point that, since the scope has been documented, reviewed and baselined, the need for active stakeholder management is diminished? Exhibit 2 illustrates a possible scenario if this happened..At some point in the project – we called it Point X – the line of communication between the project team and the customers is broken or severely weakened. The customers may think that they have provided all the relevant information, and the project team may decide that spending more time talking to customers distracts them from their active duties. What happens from that moment on is that an expectations gap starts to appear on the project, a gap between what the customers want and what the project team will deliver. This divergence can occur for a number of reasons, including change in customer preferences, technical abilities of the project team or imperfections in the original scope documentation to name a few.

Exhibit 2

The end result of this process is almost always very sad and disheartening. Customers show up at the end of the project, inspect the results and find a lot of mistakes, deficiencies and discrepancies between the final product and their own expectations, either real or illusory.

Why Do Changes Happen?

So, why do scope changes happen on the projects? No matter how we, project managers dislike unexpected alterations, in many cases they do have a rightful basis. Exhibit 3 lists some of the reasons of why changes can happen on projects along with some relevant examples.

Exhibit 3

Type Of Change	Explanation/Example
Large scope and complexity of the product	Chances that some scope items could be overlooked increase drastically when one compares building a family house with the construction of a modern port terminal
Poorly or loosely defined requirements	Not enough time was allotted for proper scope definition or the requirements specialists were not trained properly
Changes in business objectives and plans	R&D budgets were cut or the weight of the company portfolio has shifted to other priorities
Technology changes	Competitors released a new product with new and “cool” features and the company management feels that these features should be added to their own product
Changes in laws, policies, directives, etc	Government agency implemented new regulatory rules in the middle of the project
Customers and users who change their minds about things	Customer realized that a house with a pool, a tennis court and a four-car garage will look more imposing than a house without all these features
Customers and users who learn “neat” ways of doing things	Customer read a trade magazine and discovered that “engineered stone” countertops are more attractive and durable than the laminate countertops
Technical team members “independently” decide to improve the product	Team member learned about a new technology or saw an interesting feature in the competitor’s product and unilaterally decided to tinker with the scope

How Much Do Things Change?

Much like a miniscule interest rate compounded with necessary frequency can drastically impact the size of one’s debt, so uncontrolled changes can lead to a “scope explosion” on the project.

According to Capers Jones an average rate of scope change on projects is two percent per month. This doesn’t sound like much but simple calculation will yield a staggering 27% growth in the project scope over the course of one year.

To put this number in perspective, if the initial project budget was one million dollars, a scope change rate of two percent will balloon to at least $1,270,000 by the end of the year! We say “at least” because, typically, late changes in the project cost proportionally more than if the same scope items were to be implemented at the beginning of the venture.

A simple implementation of a change control process decreases the monthly growth rate to 0.5 percent, which in turn leads to approximately 6% annual increase in scope.

Exhibit 4 demonstrates various scenarios of monthly scope change rates and annual increases in the scope of the project.

Exhibit 4

Scenario	1	2	3	4	5	6	7	8
Monthly “scope growth” rate	1%	2%	5%	7%	1%	2%	5%	7%
Project duration (months)	12	12	12	12	24	24	24	24
Final scope increases by	6%	27%	80%	125%	27%	61%	223%	407%

Are All Changes Necessarily Bad?

As was mentioned earlier, it is a natural instinct of any project manager – including the author of this article – to dislike last-minute scope changes. Once you have spent copious amounts of time on scoping, scheduling, budgeting and all other related project management tasks, you want to take a deep breath, lean back in your chair and relax for a while as the well-oiled project machine is chugging along destined to deliver great results.

This brings us to a very important question that came up time after time in my class discussions and in conversations with my peers, “Is all change in scope on the project inherently bad?”

We all know of examples when scope creep has devastated projects, driving them to be late and over budget, or delivering graceless monstrosities that nobody wanted. Having said that, are there any good changes that improve the final outcome? Discovery of a major flaw in the original design, new risks that could not have been foreseen, change in the market conditions – shouldn’t we try to address these changes as soon as possible? The key question for the project manager and the rest of the stakeholders including customers and users is purely economical:

“Is the value of implementing the proposed change minus all of its negative impacts higher or lower than the cost of not carrying it out?”

For example, imagine that you are on a multi-day hiking trip. You are not familiar with the area and your friends provided you with a map of the region, warning you that it was fairly outdated. On the second day of your trip you arrive at the bridge across the mountain river. You discover that the bridge is in a very poor condition and obviously has not been repaired in the last twenty or so years. You and your hiking buddies are carrying some heavy equipment and there is a small chance that the bridge will not support your weight; you will plunge from the height of 200 feet right onto a cluster of giant boulders. However, according to the map, there is another bridge 10 miles north of the first one. If your party chooses to change their itinerary and cross the river via the other bridge, the length of your journey will increase by 20 miles (10 miles in each direction). Would a sensible person accept the modification in plans and go looking for the other bridge or reject the change and proceed across the fragile one? I am fairly sure most people would choose the first option since the value of protecting one’s life is definitely higher than the twenty-mile hike and any other inconveniencies associated with it.

Let’s alter the scenario a little bit. The bridge in this scenario is still in bad condition but it crosses a very calm shallow creek. The distance between the bridge and the water surface is a couple of feet. Consequently the worst case scenario for you and your friends is that you would be forced to take a cold bath. What would an average person do in this case? The responses may vary, but I strongly suspect that the majority of people would prefer to cross the bridge because in this scenario the value of keeping yourself dry is less than the costs of an additional twenty-mile hike.

How to Manage Project Scope?

It should be fairly evident by now that “little” enhancements and improvements, if left unattended, can wreak major chaos on any given project. The history of project management contains many examples – see the beginning of this article – when scope creep had a disastrous effect on projects.

Having said that, announcing to all the stakeholders after completion of the scope definition phase that the project requirements are henceforth frozen is imprudent and impractical. As mentioned earlier, not all the changes are inherently bad. A much better approach would be to:

• Baseline the scope definition documentation when you and your stakeholders think that the document is good enough.
• Communicate to the stakeholders in general, and to customers in particular, that they will be subject to the project management pentagon laws; i.e. in order to add or even remove features, usually project budget, duration, number of resources and/or quality will have to suffer.
• Also explain that the cost of implementing scope changes tends to be directly correlated with how late in the project they were submitted – implementation of technical change right after the end of the planning stage and implementation of the same request one week before project close-out will differ dramatically in the cost and the effort required.
• Begin the execution stage of the project and manage the inevitable changes by trying to minimize their affect on the project.

The proper execution of the last point can be facilitated by using a proper change control process. When implementing scope change control, try to avoid complicated procedures; scope management should be as simple and efficient as possible. Keep in mind that if the process is too complicated and cumbersome, the stakeholders will almost always find some creative ways to circumvent it. This is usually accomplished by communicating and sometimes applying political pressure directly to the project technical team, thus removing the project manager from the equation completely.

Exhibit 5

Exhibit 5 demonstrates typical change control methodology. Once the request for a change has been made, it has to be reviewed by the project team to assess all the potential impacts. The stakeholders are presented with all the pros and cons of the new modification with respect to budget, timeline, possible risks, impact on quality, etc and the go or no-go decision is made. In the event of a go decision, all relevant project documents should be updated.

What Does a Good Change Request Look Like?

I started using a Change Request template similar to the one shown in Exhibit 6 quite early in my career and came to love and appreciate this great tool. Let me explain why. The top part of the document called “Section A” is the actual request to alter the scope of the project. The interesting aspect is that the document requires the customer to fill out this part to the best of his ability. Because of this, I came to refer to this part as the first filtration mechanism on the path of the scope creep. A typical conversation between the project manager (PM) and the change petitioner (CP) goes something like this:

CP: “Hey, Jamal, I have been talking to Bob in Marketing and he told me that it would be really cool to add “
PM: “That’s great. I will send you a change request template …”

CP: “Why?”
PM: “Well, because, since you are the requestor, it is logical to assume that you are the one who knows the most about the details of scope and the value this feature will add to the final product …”

CP: “And?”
PM: “Don’t worry, you will have to provide some basic information, describe the change in as much detail as possible and provide the reasons for this modification. It shouldn’t take more than thirty minutes …”

CP: “OK, I will give it a try.”
PM: “If you encounter any problems with the document, give me a shout. I’ll gladly help you out!”

Dear reader, out of every of ten such conversations in how many cases do you think I ever heard from the person again? At most two or three times. An economist would describe this phenomenon in the following manner, “The total utility of not filling out this document was far greater than the utility he was expecting to derive from implementation of this change”. Or, to put this into more colloquial terms, “This scope change is not even worth half an hour of my time”.

Exhibit 6

What is the Impact of the Change?

Assuming this change was indeed worth the thirty-minute effort, the next step is to assemble either your entire project team or at least all of the technical team leads from different areas. The job of these people is to assess the combined impact of such request on key dimensions of any project: scope, time, budget, duration and quality. The questions that should be asked of the project team are presented in Exhibit 7

Exhibit 7

Type Of Questions	Specific Questions
What is the technical impact?	Are there any conflicts with other scope items? Is there an impact on blueprints, bills of materials, technical drawings, design documents, etc? What other documents will have to be updated?
What is the impacts on timeline and budget?	Technical work to be done by engineers, construction crew, developers, architects, etc. Management work to be done (project manager’s time) Documentation to be updated Meetings you need to conduct (everyone involved) How will the change affect the sequence, dependencies, effort and duration of all the tasks in the project plan? What is the impact on budget?
Other impacts	Is the requested change feasible with all known constraints and staff skills? Will the change affect any indirect areas like marketing, public relations, customer support, training, etc.? What is the impact of the change on all other areas of project management including quality, communications, etc.?

As a result of this exercise all of the segments in Section B should be filled out and the merit of the change request should be discussed either between the project manager and the customer or it should be analyzed by the Change Control Board. Based on my professional experience out of the remaining six or seven customers who filled the request form, approximately five or six decide not to go ahead with the modification requested because of the combination of negative impacts outweighs the value such change will bring to the project.

Documentation

While I have made a promise not to concentrate on specific methodologies or frameworks like Agile, traditional PMI-style or any other types of project management approaches, I still think this would be the right point to talk about the documentation management on projects. There are a number of issues I have witnessed while working as a project manager:

• Change gets implemented but the documentation is not updated
• Several versions of the same document are being used by the project team and the stakeholders
• Several people have access to the same document and can add or delete information without other people’s knowledge
• Project stakeholders are not aware or do not have access to the project document repository

Here are some recommendations regarding document management on projects. First, implement and maintain the version control of the documentation. For example, before the document has been signed-off (baselined, approved, etc.) it gets version numbers in the following format: 0.N, i.e. 0.1, 0.2, 0.3, etc. Once the document has been signed-off or approved the numbering system switches to 1.N, i.e. 1.0, 1.1, 1.2 etc. In both cases the version number increases by 0.1 every time the document owner makes a change. This helps a lot in avoiding confusion with various versions of the same document existing in different forms – as attachments to old emails, documents saved on peoples’ computers, hardcopies lying around on employees’ desks, etc. When one of the stakeholders inquires about project documentation, a team member should ask “What version of the document are you looking at?”

Experience shows that having two or more people with read/write access to the project document is a very likely recipe for a disaster. It would require an unimaginable level of communication and between the document authors to ensure that all changes and updates to the document are be synchronized properly. Therefore, a more efficient model is when a “one author – one document” relationship is maintained throughout the project.

Finally, the project manager shouldn’t assume that all the stakeholders regularly check the project documentation folder on the shared drive and are aware of all the changes and updates made to documents. It would be a good practice to send a broadcast e-mail to all the relevant parties every time any of the key project documents get updated:

“Please note that Project Plan document for the Deltaport Terminal project has been updated. Project budget information in table 3.8 now reads, ‘The project budget for the Deltaport Terminal project shall be $125 million +/- $20 million.’ The latest version of the Project Plan document is now version 1.15”

Article Summary

Once the project moves into the execution phase, scope and customer expectations management become one of the key responsibilities of the project manager.

Management of customer expectations is needed because people are not always logical and may have differing perceptions. Team members should also be controlled in order to avoid “gold plating”.

There are several reasons why changes may arise on projects. These could include poorly defined scope, shifts in strategic business objectives and technology, as well as regulatory laws. Furthermore, some customers request modifications, either because they change their minds about the project scope or they discover new, previously unknown features.

Uncontrolled changes, even if imperceptible at first, can quickly snowball into serious complications: project scope can balloon by 50%, 100% and even 400%.

Project managers working at companies that tend to suffer from chronic scope increases are strongly advised to add future scope creep to their estimates. Capturing historical data regarding scope changes on previous projects is, therefore, highly recommended.

Not all scope changes are inherently bad. Every request for modifications or additions to the project scope should be assessed by answering the following question, “Is the value of implementing the proposed change minus all its negative impacts higher or lower than the cost of not carrying it out?”

Follow a process to deal with changes. Depending on the complexity and size of your projects, the formality of the process will vary but analyzing the change and assessing its impacts on all aspects of the project is essential.

Keep in mind that such analysis could be quite costly, especially late in the project. Assessments of change requests almost invariably add time and financial cost to the project regardless of whether they were approved or rejected at the end of the day!

Finally, make sure that all the contents and the versions of relevant documentation are kept up-to-date and communicate those changes to all relevant stakeholders.

Bibliography

1. “Histrionics: A Treasury of Historical Anecdotes” by Geoffrey Regan (Hardcover – Oct 15, 1996)
2. “Brassey’s Book of Naval Blunders” by Geoffrey Regan (Paperback – Aug 1, 2000)
3. “The Art of Project Management (Theory in Practice (O’Reilly))” by Scott Berkun (Paperback – April 21, 2005)
4. “Estimating Software Costs: Bringing Realism to Estimating” by Capers Jones (Hardcover – April 19, 2007)
5. “Economic Principles: Seven Ideas for Thinking … About Almost Anything” by Douglas Allen.
6. “Software Requirements, Second Edition (Pro-Best Practices)” by Karl E. Wiegers
7. “Effective Requirements Practices” (Addison-Wesley Information Technology Series) by Ralph R. Young
8. “Exploring Requirements: Quality Before Design” by Donald C. Gause and Gerald M. Weinberg
9. “Requirements by Collaboration: Workshops for Defining Needs” by Ellen Gottesdiener (Kindle Edition – Feb 17, 2009)
10. Mastering the Requirements Process (2nd Edition) (Hardcover) by Suzanne Robertson and James C. Robertson
11. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
12. “Project Management” by Robert Santarossa

Don’t forget to leave your comments below

---

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev also offers the following corporate seminars through his company:

“Practical Portfolio Management – Selecting & Managing The Right Projects”
“Successful Hands-On Management of IT and Software Projects” 
“Successful Hands-On Management of Modern-Day Projects” 
“From Waterfall to Agile – Practical Requirements Engineering”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca