CHAPTER 3
PROJECT SUCCESS AND
STRATEGY
In Chap. 2, we defined the project objectives: the desired project outcome, the desired performance improvement, and the problems or opportunities that the new asset will solve to help achieve that performance improvement. We then defined the project output, the new asset, and the new capabilities it will give the firm to enable it to solve the problems or exploit the opportunities to achieve the desired benefit. Figure 1.9 suggests that as we cascade down the product breakdown structure, before defining the objectives at the next level, we should define a strategy for how to achieve the objectives at the current level. So before we begin to plan the project we should derive a strategy for achieving the overall project objective. The first step of that is to round off the definition of the objectives by determining the criteria by which we will judge their successful achievement. Then you can determine what factors will increase the chance of achieving, and from them derive a strategy for implementing the project.
There are two components of project success:
1. Success criteria: The dependent variables by which we will judge the successful outcome of the project.
2. Success factors: The independent variables which will influence the successful achievement of the success criteria.
A doctoral student of mine, John Wateridge, identified what I consider to be a necessary condition for project success.1 In order for a project to be successful, you must agree the success criteria with all the key stakeholders before you start. This is a necessary condition for project success, not a sufficient condition; unfortunately there is nothing that will guarantee project success. To meet this condition you must make an attempt to identify who most of the key stakeholders are. There are several reasons why it is important to agree the success criteria before you start, including:
You want everybody to have the same vision of the end point of the project. If people have been working towards different end points, even inadvertently, it is impossible to pull them all together at the end.
You want everybody to be applying the same success factors, following the same project strategy, and following the same road to its successful achievement. You don't want the project team members all chasing off in different directions.
Even quite small differences in interpretation of the success criteria can lead to quite different outcomes, even down to whether you treat time, cost, or quality as more important (see Example 3.1).
Example 3.1 Different interpretations of the importance of time, cost, and quality
A colleague of mine was working with a shipbuilding company that had traditionally built submarines. They wanted to move into surface ships. The Ministry of Defence (MOD) issued an invitation to tender for a frigate, so the company decided to win the work to demonstrate to the MOD that they could successfully build frigates. Their strategy was to bid the job at no profit and then complete the job on time and to quality to demonstrate their competence in this area. They successfully won the bid, but nobody thought to tell the project manager the company's strategy. He saw that the project was likely to make a loss, and went all out to reduce cost. As a result quality suffered and the project went late. (Actually the parent company also changed part way through the project, and as in Example 2.7 the new parent company set different objectives for the subsidiary.)
We judge the success criteria at the end of the project, and in the months and years following. But we don't want to wait until the end of the project and find we have gone off target at the start. There are also key performance indicators, measures of the success criteria which we can track throughout the project to ensure we are on course to achieve a successful outcome.
In this chapter, I consider the issue of project success. I identify potential success criteria for projects. We see different stakeholders judge success in different ways, and it is important to achieve a compromise between their different views, to achieve an overall balanced view of success. I then describe key performance indicators, and indicate ways in which they can be simply and visually tracked through the project. Having identified the success criteria, we then need to identify the success factors which will help us achieve those criteria. I used to talk about pitfalls, things that will trip us up on the project. Now I like to take a more positive view and talk about active things we can do to increase the chance of success. In the process I will identify four necessary conditions for project success. I will then describe two models for developing a project strategy: the seven forces model and the project excellence model. Finally I will describe five principles for project success which pervade the ideas in this book.
The standard mantra for how we judge project success is that it should be completed to time, cost, and quality. However, this is simplistic in the extreme, and can be positively dangerous. There is an apocryphal story of research done in Australia which looked at how people viewed the success of software projects 5 years after implementation. It is said that every project that was finished on cost and time was judged 5 years later to be a failure. The point is that in striving to finish on cost and time the project manager sacrificed functionality, and the users had to live with poor functionality for 5 years. Even the project team may get satisfaction from other things (Example 3.2). I also said in Sec. 1.2 that by focusing on time, cost, and quality, project managers are distracting their attention from what is important on projects: the need to manage the uniqueness, novelty, and transience, and the inherent risk and need for integration that those create.
Example 3.2 Finishing the project on time
I worked as a maintenance engineer on four ammonia plants in the northeast of England. Every 6 months we closed a plant for biennial refit. Over a period of 4 weeks we did 100,000 man-hours of work. We planned the overhauls to within 4 hours, but we were usually 2 days late. But we were only 2 days late. We pulled out all the stops, and managed our way through all the problems to deliver the project within 2 days of target. Once we coasted in 4 hours early, and felt we had failed. If we had been given a tighter target we could have really proved ourselves and achieved a shorter duration!!! That overhaul did not fulfil our need to prove ourselves as managers.
In his research, John Wateridge asked people working on information systems projects to think of two projects they had worked on, one a success and one a failure, to say what their role had been (sponsor, user, designer, or project manager), and to say how they judged each project to be a success or failure. On almost all the successful projects, all four types of stakeholder said that the project had been successful because it provided value for the sponsor. On unsuccessful projects they gave different responses as to why it had failed:
The sponsors said the projects had failed because they hadn't provided value.
The users said they failed because they hadn't provided the functionality they wanted.
The designers said they failed because they were not a good design.
The project managers said they failed because they finished late and were over budget.
What a surprise! If all the project stakeholders are working towards the same objective, to provide value for the sponsor, the project is a success, but if they focus on different things they tear themselves apart and the project is a failure. Yes, the users are interested in functionality, the designers in the design, the project managers in cost and time. But on successful projects those stakeholders bring what is important to them and balance it against the needs of others to come up with an overall compromise that meets the overall need of delivering a beneficial change that provides the sponsor with value. On unsuccessful projects, people are focusing on what is important to them to the detriment of others, and tear the project team apart.
The relative importance of the different criteria also differs project by project. The team needs to understand what is important for their project, and agrees it before they start:
In Example 3.1, time and quality were important.
In the Olympic games, after 6 years of preparation they have to be ready to the nearest minute—the time of the starting ceremony has been set, the television companies have sold their advertising. It has to start exactly on time.
Work done by the consultants McKinsey in the late 1980s showed that on product development projects the functionality of the new product has the greatest impact on value, time to market is very important, and cost is of almost no importance.2
When I describe Wateridge's results, some project managers say that they hear what I say, but in their company, in their annual appraisal, they are judged on how many of their projects were finished on cost and time. That is what determines their annual bonus, not the value of the projects to the sponsor. They ask me what should they focus on, cost and time, or value to the sponsor. I say they should focus on changing the appraisal system so that it is supportive of good project management.
Table 3.1 gives a wider range of success criteria than Wateridge's basic four. This table shows the primary stakeholder interested in each of the success criteria. As I have said, these criteria are potentially incompatible. If, at the start of the project, you work on achieving a negotiated compromise, you can achieve an overall balance which meets the needs of everybody. If you wait until the end of the project you will be trying to reconcile the irreconcilable. Table 3.1 also shows that the final assessment is made at different times. The bottom three items relate to the work of the project and the project's output. They are assessed as the project is completed. The middle three relate to the project's outcome: does the project perform as expected and produce the desired benefit. That becomes obvious in the months following the project. The top three relate to the higher level strategic goals, and
TABLE 3.1 Project Success Criteria
| ||
Measure of success | Stakeholder | Timescale |
| ||
The project increases the shareholder value of the parent organization | Shareholders | End plus years |
The project generates a profit | Board | End plus years |
The project provides the desired performance improvement | Sponsor | End plus years |
The new asset works as expected | Owner | End plus months |
The new asset produces a product or provides a service that consumers want to buy | Consumers | End plus months |
The new asset is easy to operate | Users | End plus months |
The projects is finished on time, to budget, and with the desired quality | All | End |
The project team had a satisfactory experience working on the project and it met their needs | Project team | End |
The contractors made a profit | Contractors | End |
| ||
can only be determined 1 or 2 years into the future. (Table 3.1 is phrased in terms for the private sector, but similar criteria can be determined for the public sector.)
Eddie Westerveld in his project excellence model used a much simpler set of success criteria.3 He suggested a project was successful if it satisfied the needs of various stake-holders, without specifying what their needs are, as Table 3.1 does. The five groups of stakeholders he focused on are (Fig. 3.4):
The client
The project team
Users
Contractors
Others
Ralf Müller and I, in our research of the leadership style of project managers4, extended this list (Table 3.2). We investigated how different leadership styles are appropriate on different types of projects (see Sec. 4.5). Finally, two clients of mine had very simple success criteria for their product development projects: The project should meet its first year revenue targets and provide increasing revenue in subsequent years. To achieve this the project must achieve quite a few of the requirements in the middle three rows of Table 3.1: It must work, the customers must like it, want to go on buying it, and new customers must want to buy it. It is then also likely to make a profit and increase shareholder value. The essence of Table 3.1 is captured by this simple statement.
Hartman's Three Questions
Francis Hartman5 suggests that during the start-up process you ask the project team three questions to help identify the success criteria and the stakeholders for the project:
Q1: On the last day of the project what will the project team deliver to the operations team?
Q2: How will the successful achievement of that be judged?
Q3: Who has an opinion on questions 1 and 2?
TABLE 3.2 Project Success Criteria Used by Turner and Müller4
|
Project success criteria End-user satisfaction Supplier satisfaction Team satisfaction Other stakeholders' satisfaction Performance in terms of time, cost, and quality Meeting user requirements Project achieves its purpose Customer satisfaction Reoccurring business |
|
The first question ensures that the team has a common understanding of the project deliverables. Francis Hartman reports examples where teams had a quite fundamental misunderstanding of the project deliverables (Example 3.3). The second question identifies differing opinions about the success criteria. You are not only looking at the end of the process to get agreement on the criteria: during the process you are looking to identify where differences exist, so they can be discussed and a compromise reached. The last question identifies key stakeholders.
Example 3.3 Differing interpretations of success criteria
Francis Hartman describes running start-up workshops with each of two companies, where the project teams gave contrary answers to his three questions.
The first project was the construction of a petrochemical complex in Alberta. There were two project managers, one for the design stage of the project and the other for construction. In response to question 1, one said the project was over at mechanical and electrical completion, and the other said that it would be over when the plant delivered 60 percent of its design capacity, two dates at least 3 months apart, and yet both gave the same completion date.
On the other project, the team was replacing the accounting software for their organization. About 30 people attended the workshop, and responses to the first question ranged from
– Beta test successfully completed
– The system has run for 12 months without fault
– Thirty people have been made redundant
The first two of these were now at least 15 months apart. The third was unfortunate because some of the people in the room were those to be made redundant and this was the first they had heard of it.
The teams probably blamed failure of their projects on circumstances beyond their control, saying "We were unlucky."
In Chap. 11, I describe how to build these questions into the start-up process, and in Chap. 18, I give a Project Health Check, which asks for checks if agreement has been reached.
Case study. Table 3.3 shows the answers to the three questions for the CRMO Rationalization Project.
TABLE 3.3 Hartman's Three Questions for the CRMO Rationalization Project
| |
| TriMagi Project success |
| |
Deliverables | The project will deliver to the parent organization: – Three call receipt offices, two diagnostic offices, and four filed offices – The technology to support the operation of the new system – Operational procedures to operation of the new system – Working methods to support the new system – Adequate numbers of competent people to support the new system |
Success criteria | The project will be judged successful if – There are never any engaged telephones in call receipt – An engineer always arrives on site within 2 hours of a call being logged – There are improvements in flexible working and productivity – There are fewer customer complaints – The new structure supports the company's expansion plans |
Stakeholders | Relevant stakeholders include – The board of the parent company – Managers in the CRMO organization – Staff in the CRMOs – Customers – Managers of the new regions being established – Etc |
| |
3.2 KEY PERFORMANCE INDICATORS
The success criteria should be agreed with the stakeholders before you start, but you don't want to get to the end of the project and find you are well off target, and have been so since the early days of the project. In order to avoid that happening, it is necessary to track control parameters which measure progress towards achievement of the success criteria. Throughout the book I will give guidance on how to measure the key control parameters. In modern jargon, these key control parameters are called key performance indicators (KPIs). They give a measure of the performance of the project.
It is important in project reports to give a clear and visual representation of these control parameters. There are a number of tools for doing this. The first is the project dashboard (Fig. 3.1). For any quantitative KPI, it is possible to give an indication of the current performance of that KPI against the target. In the figure, the cross where the first and second box meet represents the planned out-turn for that KPI. The arrow underneath shows the current prediction, the way the needle on your car dashboard shows the speed or level of fuel, for instance. In case a colour version of the diagram, the first box would be green, the second yellow, and the third red. This colour scheme was introduced by the Lockheed Aircraft Corporation. Green means at or ahead of plan; yellow means just behind plan, but controllable; red means well behind plan and in crisis. So you have a visual representation of the current status of that KPI. Quantitatives that you may want to track can include:
Time
Cost
Forecast first-year revenue
Safety
Variations in design
Productivity
FIGURE 3.1 Project dashboard.
We see the project manager can be made responsible for forecasting first-year revenue. So, although it is probably not appropriate to make their annual bonus dependent on the total value of the project to the sponsor, which may be dependent on revenues from 5 or even 10 years, it is appropriate to make it reflect revenue from the first year—appraisal systems can be made compatible with effective project management. Figure 3.1 also shows that you can use the traffic light system to represent performance against qualitative criteria. Now you would just show the traffic light indicating red, amber, or green depending on your assessment of that criterion. I have seen people representing stakeholder satisfaction in this way.
The project dashboard provides a very effective visual representation of project progress today. However, the weakness is it does not show how progress has changed from the previous report. The project may be getting worse, it may be getting better, or there may be no change. We simply don't know. It would of course be very simple to produce a moving marker, like a seismograph. That would be very easy. However, other tools have been developed that show how the KPI is changing with time. Earned value reports (Chap. 8) show how cost performance is changing, and milestone tracker charts (Chap. 9) show how time performance is changing. These can be combined with a report against the milestone plan (Chap. 5) and a risk report (Chap. 10) to provide a complete overview of how the project is progressing (Fig. 3.2). I will return to traffic light reporting when I describe portfolio management in Chap. 16.
Project success factors are elements of the project or its management that can be influenced to increase the chance of achieving a successful outcome. The reverse, pitfalls, are management mistakes which increase the chance of failure.
The earliest work on project success factors was done by Kristoffer Grude in Norway. This was reported in the first Norwegian edition of the book Goal Directed Project Management.6 Kristoffer Grude, in his work as managing director of a Norwegian software company, identified a number of pitfalls. At the end of every project his staff had to record what went well or badly on their projects, and from this they compiled the list of pitfalls. I present the reverse as a list of project success factors below. The most often cited work is the list compiled by Jeffrey Pinto in his Ph.D.7 Jeffrey Pinto identified ten success factors,
FIGURE 3.2 A single page progress report for the project.
listed in order of importance in Table 3.4. During the 1990s, work on project success focused on success criteria, but returned to consider success factors in this decade. Terry Cooke-Davies differentiated between the success of the project and the success of project management8 (see Table 3.5). Jim Johnson, the managing director of the Standish Groups, has identified 100 pitfalls in information systems projects, which he describes as 10 items within each of 10 areas. The 10 areas are given in Table 3.6.
Up to this point, the literature almost studiously ignored the project manager's competence as a success factor on projects. It was implied that as long as the project manager used the right tools, the project would be successful. Terry Cooke-Davies identified organizational project management capability as a success factor (I consider this in Chap. 18). One of Jim Johnson's areas covers project management competence. Ralf Müller and I looked at the project manager's leadership style as a success factor on projects.4 We found across the board that the project manager should exhibit high emotional intelligence. We also identified specific leadership competencies that contributed to project success for different types of project. I describe these results further in the next chapter.
Success Factors
I would now like to review, the success factors from the book Goal Directed Project Management.6 In that book, they are presented as pitfalls, but I present them here as success factors. We identified success in four stages of the management process:
1. Establishing the project
2. Planning the project
3. Organizing and implementing the project
4. Controlling the project
TABLE 3.4 Pinto and Slevin's List of Success Factors
| |
Success factor | Description |
Project mission | Clearly defined goals and direction |
Top management support | Resources, authority, and power for implementation |
Schedule and plans | Detailed specification of implementation process |
Client consultation | Communication with and consultation of all stakeholders |
Personnel | Recruitment, selection, and training of competent personnel |
Technical tasks | Ability of the required technology and expertise |
Client acceptance | Selling of the final product to the end users |
Monitoring and feedback | Timely and comprehensive control |
Communication | Provision of timely data to key players |
Troubleshooting | Ability to handle unexpected problems |
| |
Establishing the Project. These are factors in the way the project is set up within the parent organization.
Align Project Plans with Business Plans. Project plans must be derived from the business plans (see Sec. 2.4 and Example 2.1). A mistake often made is to start with detail planning, and then finding it difficult to link the project back to corporate plans. Start at the top and work down (Figs. 1.9, 2.7, and 2.8).
TABLE 3.5 Terry Cooke-Davies' List of Success Factors
| |
Project management success factors contributing to time completion | |
| |
F1 | Adequacy of company-wide education on risk management |
F2 | Maturity of organization's processes for assigning ownership of risk |
F3 | Adequacy with which a visible risk register is maintained |
F4 | Adequacy of an up-to-date risk management plan |
F5 | Adequacy of documentation of organizational responsibilities on the project |
F6 | Project or stage duration as far below 3 years as possible, preferably below 1 year |
| |
Project management success factors contributing to budget completion | |
| |
F7 | Changes to scope only made through a mature scope change control process |
F8 | Integrity of the performance measurement baseline |
| |
Additional project success factors contributing to successful benefits realization | |
| |
F9 | Existence of an effective benefits delivery and management process that involves the mutual cooperation of project management and line management functions |
F10 | Portfolio and program management practices that allow the enterprise to resource fully a suite of projects that are thoughtfully and dynamically matched to the corporate strategy and business objectives |
F11 | A site of project, program, and portfolio management metrics that provide direct line-of-sight feedback on current project performance and anticipated future success, so that project, program, portfolio, and corporate decisions can be aligned |
F12 | An effective means of learning from experience on projects that combine explicit and tacit knowledge in a way that encourages people to learn and to embed that learning into continuous improvement of project management processes and practices |
| |
TABLE 3.6 The Standish Group's Ten Areas of Success Factors
|
Ten areas of project success factors User involvement Executive support Clear business objectives Scope optimization (lean) Agile processes (iterative) Project management expertise Financial management Skilled resources Formal methodology Tools |
|
Define Procedures for Managing Projects. Projects use transient teams to undertake novel assignments. The teams form quickly in order to undertake the task successfully. A properly structured start-up process is therefore important (Chap. 11). A consistent, company-wide approach to project management can also help (Chap. 17). However, it is necessary to obtain a balance between the need for a company-wide approach and the need to respect the individuality of project types.
Communicate Priorities to the Parties Involved. Example 3.1 shows what can happen when priorities are not communicated. People assign their own, usually different, priorities, with the result that there is no coordination, and no work is done. Agree the success criteria with the stakeholders before you start.
Planning the Project. The following factors are among those that determine how the work is defined and, the time and cost schedules calculated and communicated to the project team.
Develop Project Plans Developed on Multiple Levels. The use of breakdown structure is how we ensure the work delivers the required benefit. The usual pitfall is to plan at a detailed level only; computer software unfortunately encourages this. Sometimes work is planned only at a very high level, and there is no coordination. The following Chinese proverb illustrates that in almost every area of human endeavour work is planned on many levels. Projects should be no different:
A journey of a thousand miles begins with a single step (Lao Tsu).
On a journey there are at least two levels of planning between the end objective and the steps: the milestones (towns and villages), and the route map (roads). The former is the strategic plan, comprising intermediate goals or products, and the latter the tactical plan. At the milestone level, we make our plan robust but flexible, providing key fixed points for measuring progress towards our objective but able to incorporate changes at a lower level without changing the milestone definition. The road map we also try to keep fixed. However, there are two ways we can build in flexibility. If we find the route blocked, we can make a detour, but still aim to reach the next milestone. Sometimes the detour is better than our original route, but changes are contained at a low level. We can also adopt rolling-wave planning. We do not need to define the route between the last two towns until we reach the penultimate town. Sometimes we cannot get that information until we get there. All we need to estimate is the distance between the towns to plan the time and cost of the journey. The single steps are planned as we progress.
Use Simple Planning Tools. The complexity of project planning tools has grown over the last 40 years, due to the increasing power of software. However, at best complex plans achieve nothing; at worst they confuse the situation (see Example 3.4). The plans and progress reports should be cascaded through work breakdown structure (WBS) (Fig. 1.10). This can help build the vision for the project.
Example 3.4 Cumbersome, unfriendly tools
A delegate on a project management course said that he had 3 people on his project team of 20 who spent all day every day developing plans on a well-known PC-based package, and he got no useful information out. Thus 15% of his team was contributing nothing!!!
One reason why detail planning tools have developed is they were used so successfully on the Polaris Project in the United States in the 1950s. There is no doubt that Program Evaluation and Review Technique (PERT), which was first developed on the project, was a powerful analytical tool which helped identify and eliminate risk, which removed 2 years from an 8-year schedule. The project manager was also very charismatic and used the technique to help build the vision for the project. However, the following quotation illustrates a covert use of the technique:10
These procedures were valuable in selling the importance of the mission. More importantly, the PERT charts and the rest of the gibberish let us build a fence to keep the rest of the Navy out and get across the message that we were the top managers.6
Complex plans were deliberately used to confuse outsiders and discourage them from getting too closely involved in the project, thereby protecting the project team from interference. This is a valid use of complex plans, but you also need to maintain the simple plans, or you will confuse yourself.
Encourage Creativity. It is the reality of modern projects that the project manager cannot be an expert in all areas of a project. Yet it is not uncommon to see project managers dictating to people more expert than themselves through the plan, telling them how to do their jobs. This can demotivate the experts, and isolate them from the project. What the project manager should do is delegate elements of the strategic plan to the experts, telling them which milestones they are responsible for, by when and at what cost, but allowing them to determine the best method of achieving that. In this way they can retain their integrity, while meeting the project's goals.
Estimate Realistically. There are several causes of unrealistic estimates.11 It is common when preparing an estimate to believe the owner may not accept it and reduce it, or not accept the project. So people play the project management game and shave the estimates. Inevitably the work turns out as originally estimated, resulting in perceived failure. This is called strategic misrepresentation (see Example 3.5). Secondly, people may be overoptimistic about how the project will turn out; they just see things in a rosy light. This is called optimism bias. Thirdly, there may be inadequate historical data to estimate the work accurately. In that case, the risk must be identified and an appropriate contingency added. Flyvberg11 suggests that if this were the cause estimates would improve with time, which they don't. Fourthly, people have different abilities. You must plan for the people you have, not some unobtainable ideal. Finally, it is sometimes assumed that project personnel are able to work 260 days (2080 man-hours) a year. A person working full time on a project is available much less than that. Lost time is caused by holidays, bank holidays, sickness, training, group meetings, and the like. When planning, this lost time must be accounted for (Chap 9).
Example 3.5 Strategic misrepresentation and the project management game
I know somebody who was on the French team evaluating the proposals for the Channel Tunnel in the mid-1980s. He says they knew the estimates of capital cost had been halved and the estimates of revenue had been doubled, making the project look four times better than it was. But they played the project management game because they all wanted the project.
Organizing and Implementing the Project. These are factors in building the project organization and assigning work to people.
Obtain Cooperation. It is not uncommon on projects to wonder if you all work for the same organization, as covert objectives get in the way of the overt objectives. Cooperation is achieved in two ways: by building a clear vision for the project; and by negotiating agreement to the plans (Chap. 4).
Obtain Commitment of the Resource Providers. Project managers often use resources on secondment from other managers. They will not willingly release their resources if they are not committed to the project.
Ensure Resources are Available When Required. It is not adequate just to send the resource providers a plan and expect their people to be available at some point. Even if they are committed, you must ensure they understand the requirements. This is helped by using simple plans, by discussing the requirements of the plan with the resource provider, and by negotiating their release. They must also plan to release their resources at the required time.
Define Management Responsibility. When defining roles on projects, it is common to consider only those people who do the work: cutting metal or writing code. However, people have other roles which consume time or can delay the project. These tend to be management roles, especially those which cause delay. These roles include taking decisions, managing information, and managing progress.
Ensure Good Communication. Surprisingly, poor communication on projects is sometimes caused by too much rather than too little. Communication out of a project is often achieved by sending every piece of information to everyone involved. People soon learn only a few documents are relevant to them, so all go straight in the bin. The project manager must define those who need information, so that when people receive something they know they ought to read it. If some other person wishes to be included in the circulation, they must negotiate inclusion on the responsibility chart. Similarly, committees are often used for communication into a project. Once invited people tend to stay on the committee, even if they are no longer required. Committees grow organically. Worse still, it is those people who have least to contribute who do most of the talking at meetings, as they talk to justify their presence. Channels of communication into a project must be clearly defined and limited, and any additions discussed and negotiated.
Differentiate between Technical Management and Project Management. It is still common to hear design managers refer to themselves as project managers, especially on information systems projects. Often, these "project managers" are not good at delegating work. They believe, quite rightly, they can do the work better than anyone else, and so surround themselves with idle people while they work themselves into an early grave. It is my view that an industry has truly matured in the management of projects when they stop calling design managers project managers, and stop using design engineers as such. Project management is an integrative function and design management is a specialist function.
Controlling the Project. Finally, factors in monitoring and controlling progress are illustrated by Example 3.6.
I once audited a project where the manager felt he had lost control, but was unsure why. The project was to put on a trade exhibition, held in Birmingham in December. There were 15 syndicates of 4 companies collaborating in this exhibition. Work started in June. Each syndicate prepared their own material, bringing it to a test site in September, moving it to Birmingham in late November. The project manager was a contractor. In June he had a meeting with the representative of each syndicate, showed them his plan, and said if the syndicate had any problems with the plan, to let him know. That was his first and his second mistake: First, he dictated to the experts by telling them his plan, not developing a plan with them; second, lack of comment was interpreted as agreement. The project manager then held weekly meetings attended by the representatives at which they gave verbal progress reports. Each person spoke for about 15 minutes, resulting in a 4-hour meeting; but the project had been set up in such a way that no one was interested in what the others were saying. The whole point of dividing the project into 15 syndicates was each syndicate could work on its own in the early stages. Each meeting therefore consumed 64 man-hours to no effect. At each meeting the representatives usually reported that everything was going to plan. I was called in mid-September because in spite of that, materials were not arriving at the test site at the due time. The manager wondered what was going on. What had happened was that after the first meeting most of the syndicates had ignored the project manager's plan and worked on their own. When they said things were going according to plan, they meant their own, but the project manager assumed they meant his, and the two bore no relation.
Understand the Purpose of Control. The purpose of control is not to hold meetings. It is also not to punish people for failing to achieve the plan. If people believe that is the purpose of control they will withhold information. The purpose is to monitor progress, to compare progress to the plan, and to take necessary action to achieve the project's goals. That requires people to be open and honest about progress on the project. If people know they are reporting progress because it is time to report progress, and the information will be used to help and support them, they will be more willing to give a true picture of progress.
Monitor Progress against the Plan. Control was lost in Example 3.6 because people were not reporting progress against the plan. Control will only be effective if there is a common basis for control, which means a common plan. This is achieved most effectively by reporting progress on a copy of the plan.
Hold Effective Review Meetings. To be effective formal review meetings must be held, with controlled attendance, fixed criteria for reporting, and at fixed intervals. Discussing progress at the coffee machine may be part of good leadership, but it is not of good control. At the other extreme, large meetings where most people are not interested in what others are saying waste time. People must only be invited if they have something to contribute. Holding review meetings at two or more levels of the planning hierarchy can aid this. (The manager in Example 3.6 should have had weekly meetings with the representatives individually, and less frequent meetings with the whole group to discuss common issues). The meetings must have a fixed agenda, which means reporting against fixed criteria, including the plan. Without a structure people will report progress in a way which puts them in the best light. Finally, people sometimes hold meetings only when they have something to discuss. By then control is reduced to damage limitation. Meetings must be held at fixed intervals, although the frequency may vary depending on the risk, and the point in the project life cycle.
Combine Responsibility with Authority. The manager in Example 3.6 had no direct authority over the syndicates, and was not able to use other sources, including that obtained by negotiating agreements. Without authority for control, the manager cannot take action to achieve the project's goals. I describe in Chap. 6 sources of authority available to the project manager.
Five Necessary Conditions for Project Success
Two Ph.D. students of mine, John Wateridge1 and Ralf Müller12, have between them identified what I believe to be five necessary conditions of project success.
Key Stakeholders Should Agree on the Success Criteria before You Start. I started this chapter by explaining the importance of this. It will repeatedly recur throughout the book.
Continue to Confirm Agreement at Configuration Review Points throughout the Project. It is not enough just to agree the project goals once at the start of the project; you need to ensure that people maintain a common vision of the project's outcomes throughout. This can be done at configuration review points (Chap. 7), and project gateway reviews (Chap. 18).
Maintain a Collaborative Working Relationship between the Project Owner and Project Manager, with Both Viewing the Project as a Partnership. There is increasing evidence that in order to have a successful outcome, the project owner and project sponsor must work together in partnership towards mutually beneficial goals. They must play a win-win game. Unfortunately they so often try to outdo each other, viewing the project as a fixed cake, and each tries to benefit at the others expense. They play a win-lose game. But there are no win-lose games on projects; it is either win-win or lose-lose. If the owner and manager try to play a win-lose game, they will both lose; one will just lose more than the other.
Empower the Project Manager, Setting Medium Levels of Structure. Unfortunately the owner often tries to impose rigid structures on the project manager to maintain control. The result is the project manager has no flexibility to deal with risk. But the other extreme doesn't work either. If the owner gives no guidance, laissez-faire management and anarchy reigns. In fact the owner should impose medium levels of structure. Agree the goals with the project manager and set parameters within which the project manager should operate to achieve those goals, but allow the project manager flexibility to deal with risk. Also, as I mentioned in Sec. 1.2, the owner can release authority to the project manager between stage-gate reviews, knowing they can take it back at those times.
The Owner Should Take an Interest in Project Performance. Ralf Müller observed that where the owner took an interest in progress the project performed well, but the owner usually thought the project was doing less well than it was. Where the owner didn't take an interest in progress, the project didn't perform well, and the owner had a rosy picture of progress. In Chap. 15, I will describe communication between the project manager and sponsor to satisfy the sponsor's needs for comfort.
3.4 THE STRATEGIC MANAGEMENT
OF PROJECTS
Having identified the success criteria for your project, and the relevant success factors, the next step is to develop a project strategy. Several models have been developed for this, and I present two here.
The seven forces model (Fig. 3.3) is a model I developed from the work of Peter Morris.13 It shows that there are seven forces acting on the project.
External context: Two forces are imposed by the external context, as described in Chaps. 1 and 2:
External influences: The political, economic, social, technical, legal, and environmental (PESTLE) influences of and on the parties involved.
Sponsorship and schedule: The finance provided by the owner, the benefit expected in return, and the timescale which makes that benefit worthwhile, and will repay the finance.
Project strategy: Two forces arise from within the parent organization, from the strategic importance given to the project, and the strategy for undertaking it:
Definition: What the project is required to do, the approach to its design and technology expected to deliver it.
Attitudes: Representing the importance attached to the project and the support given from all strata of management, from the leaders to the followers.
Internal implementation: Three driving forces come from within the project:
People: Their management, leadership, teamwork, and industrial relations.
Systems: Planning, reporting, and control are the systems by which progress will be measured and managed.
Organization: The roles, responsibilities, and contractual relationships between the parties involved.
FIGURE 3.3 The seven forces model of project management.
External Influences. As well as being the primary influence of corporate strategy, external influences are a primary cause of many project overruns.9, 13 In Sec. 2.2, I introduced the analysis of these factors as political, economical, sociological, technical, legal, and environmental factors (PESTLE) Analysis. We might ask how much the project manager can influence these factors. Often some influences can be exerted, if only to provide protective action or contingency.
Most projects raise political issues, and hence require political support. These issues must be considered from the outset. People working on a project must be attuned to them and be ready to manage them. To be successful, project managers must manage upwards and outwards, as well as downwards and inwards. The project manager should court the politicians and influential managers, helping allies by providing information needed to champion their program. Adversaries should be co-opted, not ignored.
Stakeholders, especially the local community, are an important external influence. The management of change must take account of this influence (Sec. 4.2).
Sponsorship and Schedule. The project cannot begin without finance, and that will only be forthcoming if the owner expects adequate benefit from the project (Chap. 2). Much of the project definition will be driven by the available sources of finance, the financiers wishing to minimise risk, especially in the choice of technology.
A key parameter in a project's viability is the completion date, with even a small slippage leading to a significant loss of revenue and increased financing charges. Determining the timing of the project is crucial to calculating the risks and dynamics of its management. How much time is available for each stage, together with the amount and difficulty of the work to be accomplished, influence the nature of the task to be managed. Therefore, in specifying the project, the manager should ensure the right amount of time is spent on the overall duration. Milestone scheduling is crucial. It is important that the development stage is not rushed or glossed over (a fault that has caused many project catastrophes in the past).
A degree of urgency should be built into a project, but too much can create instability. The manager should avoid beginning implementation before technology development and testing are complete. This situation is known as concurrency. (Concurrency is sometimes employed quite deliberately to get a project completed under exceptionally urgent conditions, but it often brings major problems in redesign and reworking.) Concurrency is now increasingly synonymous with fast track, that is, building before design is complete. If faced with this, be under no illusion as to the risk. Analyse the risk rigorously, work element by work element, milestone by milestone. The term "fast build" is now being used to distinguish a different form of design and construction overlap: that where the concept, or scheme, design is completed but the work packages are priced, programmed, and built sequentially, within the overall design parameters, with strict change (configuration) control being exercised throughout. With the use of fast build, the design is secure and the risks are much less.
Project Definition. The development of the project's definition is vital to its success. A comprehensive definition should be developed, stating its purpose, ownership, technology, cost, schedule, duration, financing, sales and marketing, and resource requirements. If this is not done, key issues essential to the viability of the project may be omitted or given inadequate attention, resulting in poor performance. Through the project definition, the vision for the project is created, the purpose of the project is defined, the project plans are aligned with the business plans and the basis of cooperation agreed. Project definition is described in Chap. 11, and is achieved by following the steps discussed next.
Setting Objectives. Little can be done until clear, unambiguous objectives have been set for the project. The project's success can be compromised by objectives that are unclear—do not mesh with organizational strategy—and are not clearly communicated and agreed.
Defining the Scope. Scope definition, cost, time, and performance criteria are intimately related. If they are unrealistic, expectations for the project will not be met, and it will be said to fail. The strategic plan for attaining the project's objectives must also be developed in a comprehensive manner from the start. If the project objectives change, the scope definition and investment criteria must be reconsidered.
Setting Functional Strategies. The setting of a project's functional strategies must be handled with great care, and requires the determination of the design, the technology to be used, the method of its implementation, and eventual operation best suited to achieving the objectives. The design standards selected will affect the difficulty of construction and eventual operation of the plant. Technical risk in particular needs to be assessed. Technical problems can have a huge impact on the likelihood of project overrun.13
Managing the Design Process. No design is ever complete; technology is always improving. A key challenge is to achieve a balance between meeting the schedule and making the design that fits better. Central to modern project management is the orderly progression of the design and its technical basis through a sequence of review stages. At each stage, the level of detail is refined, with strict control of technical interfaces and changes (through Configuration Management, Chap. 7, and through end-of-stage reviews, Chap. 18). Changes can result in extensive rework, as people on other parts of the project may have based their assumptions on the agreed design. You should therefore aim to achieve a progressive design freeze as soon as possible. This is usually feasible in traditional engineering projects, but an early design freeze may conflict with meeting the customer's requirements (see Chap. 7), especially in organizational development, high technology, and information systems projects. In setting up projects, care should be taken to appraise technical risk, prove new technologies, and validate the project design, before freezing the design and moving into implementation. The management of the design process is described in Chap. 11.
Resources. It is no good defining what you want to achieve if you do not have the right number of good, committed people, sufficient money, adequate infrastructure, and so on. In fact, getting adequate resources, managing them well and ensuring that the context is supportive are at the heart of successful strategic management, yet are rarely addressed by the literature on strategy. I cover resources under both the project's internal organization and its external context in Chap. 6.
Attitudes. This is probably the most important force. The chances of success are substantially diminished unless
There is a major commitment to making the project a success.
The motivation of everyone working on the project is high.
Attitudes are supportive and positive.
To achieve positive attitudes it is vital to develop a clear vision, by linking projects plans to business plans, and by functional and task managers being seen to cooperate to achieve the same objectives. It is particularly important that the project receive visible commitment and support from the top, without which it is probably doomed. However, while commitment is important, it must be towards viable ends. Great leaders can become great dictators. If sensible projects are to be initiated, they must not be insulated from criticism. Critique the project at the specification stage, and ensure it continues to receive frank reviews.
People Issues. Projects usually demand extraordinary effort from the people working on them, (often for modest reward, and with the prospect of working oneself out of a job). In Chap. 4, we will discuss how significant institutional resistance can be overcome in order for the factors listed here to be achieved. This puts enormous demands on the qualities of those working on the project, from senior management through the professional teams to artisans. The initial stages of a project may require considerable leadership and championing to get started. Beware though of unchecked champions and leaders: of the hype and optimism which too often surrounds projects in their early stages. The sponsor must be responsible for providing the objective check on the feasibility. The sponsor might be considered as the person providing the business case and the resources. Evidently they ought to be convinced of the merits of the project on as objective a basis as possible. We should recognise the importance of team working, of handling the conflicts which arise on projects positively, and of good communications. Consideration should be given to formal start-up sessions at the beginning of a team's work (mixing planning with team building) (Chap. 11). The composition of the team should be looked at from the social angle as well as the technical: People play social roles on teams, and these will be required to vary as the project evolves (Chap. 4).
Planning and Control Systems. Appropriate systems must be used to plan and control all the significant functions, including scope, quality, cost, time, risk, and other elements identified as appropriate. Table 1.2 lists many of the tools and techniques used. Plans should be prepared by those technically responsible for their work, and integrated by the project support office (Chap. 16). Initial planning should be at a broad, systems level with detail only being provided where essential, and in general on a rolling-wave basis (Chap. 5). Similarly, cost estimates should be prepared by work breakdown element, detail being provided as appropriate (Chap. 8). Cost control should be in terms of physical progress, and not in terms of invoiced value (Chap. 13). Cost should be related to finance, and be assembled into forecast out-turn cost, related both to the forecast actual construction price and to the actual product sales price. All changes to the proposed project baseline, proposed as well as actual, should be monitored extremely carefully. Implementation of systems and procedures should be planned carefully so that all those working on the project understand them properly. Start-up meetings should develop the systems procedures in outline, and begin substantive planning while simultaneously "building" the project team (Chaps. 11 and 19).
Project Organization. There are three organization issues which must be considered at the earliest stages.
Management Structure. A project structure is expensive on resources (Chap. 6.) Many projects begin and end with a functional line structure, but change to a matrix during implementation. Implementing a matrix takes time, and effort must be put into developing the appropriate organizational climate. (The issues in selecting a structure are described in Chap. 6.)
Client Involvement. The issue is the extent to which the client continues to be involved, even after hiring contractors to undertake the work. They may feel they have a legal or moral responsibility to ensure it is done to a certain standard, or may just want to ensure it is for their own comfort. The dilemma is between not being involved at all, versus constantly tinkering with the design, both frustrating the contractor and adding expense. The balance will depend on the nature of the project. A solution is to schedule milestone review points and limit owner involvement to those reviews.
Use of Contractors. No organization has the skills or resources to undertake all its project work, and must therefore buy in goods and services. At an early stage of project definition it is necessary to determine the contract and procurement strategy. Indeed, financiers may not lend money without knowing who suppliers will be, so they can judge their reliability. The selection of contractors and contract strategy are beyond the scope of this book.14
Another model of project strategy is the project excellence model (Fig. 3.4). This was first developed by Eddie Westerweld,3 but a very similar model has been developed by the International Project Management Association (IPMA), for their project excellence award. This model shows both success factors and success criteria in one model, with success factors on the left-hand side and success criteria on the right-hand side. In their project excellence award, IPMA award projects 500 points for how well they address each side of the model. I am not going to discuss this any further, since the elements of the model have been covered by much of the above discussion.
3.5 PRINCIPLES OF PROJECT MANAGEMENT
The remainder of this book focuses on five of the seven forces: definition, attitudes, people, systems, and organization. The two forces from the external context are beyond the scope of this book.14 The book describes a process-based approach to the management of projects, as outlined in Chap. 1, first describing the project management functions, the management of scope, organization, stakeholders, quality, cost, time, and risk, and then describing the project management process through the life cycle, covering definition, implementation, control, and close-out. In order to successfully address the seven forces and avoid the pitfalls, the approach described in this book is based on five principles of good project management:
Manage through a structured breakdown, with single point responsibility.
Focus on results: what to achieve, not how to do it.
Balance results through the breakdown structure.
Organize the project by negotiating a contract with the parties involved.
Adopt a clear and simple management reporting structure.
FIGURE 3.4 The project excellence model.
Structured Breakdown. Almost everything we do in life, we plan over several levels, breaking our understanding down in a structured way. Projects are no different. Using a breakdown structure lets us
Define and control the scope
Isolate changes
Isolate risk
By breaking the facility down in a structured way, we can determine its essential components required to achieve our project and business objectives. We then do work because we know it is going to deliver a result we need, not because it seems like a good idea. By dividing the project up in this way we can ring-fence elements of work and help to ring-fence changes and risk, as with changes to the journey described in Sec. 3.3. The breakdown structure is the core of project management and almost all the planning and control systems are based on it. Hence the project organization is very closely linked to the breakdown structure, and it is common to identify one person or team as being responsible for the successful delivery of each element of work at a given level. A person or team is given single-point responsibility for each element of work.
Focus on Results. The primary breakdown structure is the product breakdown structure (PBS) by which we break the facility up into its components. We plan the project in terms of the results, or deliverables, we want to achieve rather than the work to be done. The reason for this is it makes the plan robust but flexible, and because it gives better control of the scope: The plan is robust or stable, because the definition of the expected results should be stable. If the definition of the results changes substantially, the project changes as well. Even where the configuration or specification of the results may be poorly defined (Fig. 1.12 and Sec. 7.3,) we can still plan in terms of deliverables, the precise specification of which is yet to be determined. On the other hand, if we plan in terms of the work, the plan can be constantly changing, especially if the goals or methods are poorly understood, in which case the early stages of the project will define the work to be done in the later stages. It also gives better control of the scope because we only do work which delivers results we know we need to achieve. Planning in terms of the work, it is possible to define work that seems like a good idea, but which in fact does not deliver useful results.
Balance Results through the Breakdown Structure. The plan at the strategic level can be used to ensure that proper emphasis is given to all areas of work, to balance the levels of ambition for different areas of technical work, and for changes to people, systems, and organization, and to ensure they are appropriate to the project's purpose. I suggested in Sec. 2.2 that the team's attention can focus on the technical work. A balance must be achieved through the strategic plan.
Organize the Project by Negotiating a Contract. Nobody is altruistic; nobody does something for nothing. People will only work on your project because they expect some benefit in return. The expected benefit can take several forms, positive returns or absence of negative returns:
The project may contribute to the success of the organization for which you all work.
Working on the project may be the person's job, and if they do not they will not get their annual bonus.
They may like and respect you, and expect that if they contribute to your project, you will contribute to theirs.
Whatever the expected benefit, in asking for someone's contribution to your project, you must negotiate their contribution, which means
1. You must trade their inputs against expected benefits, as just discussed.
2. The agreement must be reached through open discussion.
3. The agreements must be represented through clear, simple, open, visible plans which represent the expected contribution and the promised returns.
It is not uncommon for project managers to plan their projects on their own, and then to tell the project team what they are expected to do. However, a contract is not agreed by one party telling the other party the answer; it is agreed through discussion, and trading of positions. It must be the same with the project plan. This also allows the project team to contribute their ideas, and the experts to retain their integrity by determining how they will achieve the milestones for which they are responsible. I describe group planning in Chaps. 5, 6, and 12.
Clear and Simple Reporting Structure. The plans must also be clear and simple so that the project team members can see precisely what their contribution is, and how that contributes to the objectives of the parent organization. Complex plans confuse (see the quote in Sec. 3.4); and they confuse the project team as much as they confuse the outside world. Single page reporting means
You try to represent the project objectives and the business purpose on a single page.
You develop a single page strategic, or milestone plan, representing the overall approach to the project through one to two dozen milestones.
For each milestone you develop a list of activities, showing how that milestone is going to be achieved.
1. There are two elements of project success:
Success criteria—How we will judge the project to be successful.
Success factors—The elements of the project we can influence to increase the chance of success.
2. Different stakeholders judge the project to be successful in different ways. It is important to achieve a balance of those different criteria, meeting the needs of the different stakeholders.
3. Criteria for judging project success include
The project increases the shareholder value of the parent organization.
The project generates a profit.
The project provides the desired performance improvement.
The new asset works as expected.
The new asset produces a product or provides a service that consumers want to buy.
The new asset is easy to operate.
The project is finished on time, to budget, and with the desired quality.
The project team had a satisfactory experience and the project met their needs.
The contractors made a profit.
4. Overall the project will be successful if it delivers the desired performance improvement, or better, at a time and cost that provides value for the organization.
5. In a classic piece of work, Jeffrey Pinto identified 10 success factors on projects:
Project mission
Top management support
Schedule and plans
Client consultation
Personnel
Technical tasks
Client acceptance
Monitoring and feedback
Communication
Troubleshooting
6. In setting the project up you need to consider success factors under
Establishing the project
Planning the project
Organizing and implementing the project
Controlling the project
7. There are seven forces which influence your choice of project strategy
Two from the context
PESTLE
Sponsorship
Two from the parent organization
Definition
Attitudes
Three internal project drivers
People
Systems
Organization
8. The approach to project management followed in this book is based on five principles:
Manage through a structured breakdown
Focus on results
Balance results
Organize a contract between parties involved
Keep it simple
1. Wateridge, J.H., "IT projects: a basis for success," International Journal of Project Management, 13(3), 169–172, 1995.
2. Dumaine, B., "How managers can succeed through speed," Fortune, 1988.
3. Westerveld, E. and Gaya-Walters, D., Het Verbeteren van uw Projectorganizatie: Het Project Excellence Model in de Praktijk. Dementen, NL: Kluwer, 2001.
4. Turner, J. R. & Müller, R., Choosing Appropriate Project Managers: Matching their Leadership Style to the Type of Project, Newton Square, Pa.: Project Management Institute, 2006.
5. Hartman, F.T, Don't Park Your Brain Outside: A Practical Guide to Improving Shareholder Value with SMART Management, Newtown Square, Pa.: Project Management Institute, 2000.
6. Andersen, E.S., Grude, K.V., Haug, T., Katagiri, M. and Turner, J.R., Goal Directed Project Management, 3rd ed., London: Kogan Page/Coopers & Lybrand, 2004.
7. Pinto, J.K. and Slevin, D.P., "Critical success factors in effective project implementation," in Cleland, D.I. and King, W.R., (eds.), Project Management Handbook, 2d ed., New York, N.Y.:Van Nostrand Reinhold, 1988.
8. Cooke-Davies, T., "The ‘real' project success factors," International Journal of Project Management, 20(3), 185–190, 2001.
9. Johnson, J., My Life Is Failure: 100 Things You Should Know to Be a Successful Project Leader, Boston, Ma.: Standish Group International, 2006.
10. Deal, T.E., and Kennedy, A.A., Corporate Cultures: The Rites and Rituals of Corporate Life, New York, N.Y.: Addison-Welsey, 1986.
11. Flyvbjerg, B., "From Nobel prize to project management: getting risks right," Project Management Journal, 37(3), 5–15, 2006.
12. Turner, J.R. and Müller, R., "Communication and cooperation on projects between the project owner as principal and the project manager as agent," The European Management Journal, 22(3), 327–336, 2004.
13. Morris, P.W.G. and Hough, G.H., The Anatomy of Major Projects: A Study of the Reality of Project Management, New York, N.Y.: Wiley, 1987.
14. Turner, J.R and Wright, D., The Commercial Management of Projects, Aldershot, U.K.: Gower, 2009.