Section G
Achieving Success
In defining success, one has to distinguish between success of the project and success of the project management function.
In any company with an established project management culture, the success of the project management process will be measured by beating or meeting the project objectives of safety, quality, time and cost (with a happy client). “If you can get safety, quality and schedule right, then cost (and reputation) is largely taken care of.”18 Success of the project will focus on meeting the financial returns and benefits. In other words, does the project perform as expected? From a contractor's perspective, they will want to have made a profit and, in the longer term, have established a good relationship with the client for repeat work. You are most likely to achieve this if you start the job right and do the job right. Nevertheless, owing to the diversity of the views of stakeholders, one is unlikely to satisfy all the people involved.
Project success will be measured differently, depending on the project phase. In the early phases, there will be strong external pressures (see Figure I.G.1), and success will be judged on financial and cost issues. As the project moves into the execution phases (the most sensitive to failure issues), the project and project manager will be judged on meeting time deadlines. Finally at the end of the project, commissioning and setting to work, it will be all about quality. At start up, it either works or it doesn't. Unfortunately, the quality element should have been built in to the early execution stages when the project is under pressure to meet time deadlines.
If a project is cancelled or terminated prematurely, then success will be measured by the effectiveness and efficiency of how well the project is closed down: terminating expenditure, cancelling purchases, reducing manpower and stopping man hour bookings, and so on.
In January 2000 I wrote a paper (‘Disconnected Project Management’) for the International Project Management Association 15th World Congress on Project Management, held in London in May of that year. In that paper I wrote:
Project Management does not always work. Data often quoted by the Industrial Society indicates that 77 per cent of projects in the UK fail. In the U.S. this figure is worse at 83 per cent. For specific sectors the statistics are horrific: only 7 per cent of business process redesign projects and 3 per cent of IT projects succeed. Further, 80 per cent of companies that failed had no Project Management infrastructure. The Industrial Society quotes the following reasons for project failure:
Inadequate definition Inappropriate team Poor or no planning Ineffective controls Wrong leader Poor communication. Scope not defined Unrealistic timescale
These are similar, but different, issues to many other lists.19 For example, The Business Round Table in the U.S. states that the poor definition of project scope is the primary cause of cost over‐runs followed by the loss of control during design and execution.
By contrast, W.Belassi and O.I.Tukel quote seven lists of critical success factors from…. [leading authors on the subject over almost a thirty year period]. Space does not permit providing details of these lists but, broadly, they are the positive and opposites of the causes of failure. The interesting feature of the lists is that there is almost no commonality of issues. Out of a total of 61 issues only 3 appeared in four of the lists and only one was mentioned specifically 5 times. Allowing for the different terminology, this issue ‐ project controls, could be said to have 10 mentions (but despite this did not appear in all of the lists). The author's own primary prerequisite for project success namely: ‘Alignment of Objectives’ is only mentioned three times in a variety of forms as: ‘definition of clear goals and objectives.’ Anyone who has played any version of ‘The Prisoner’s Dilemma' will know how important the ‘alignment’ part is and that personal objectives will always carry more weight because of the fact that they are in the control of the individual. Thus, whilst the literature has identified the causes of project success or failure, it has not satisfactorily explained the reasons behind these causes to help us find ways of dealing with the issues.
Having collected lists of success factors from various sources over the years, it is difficult to disagree with any of them. Whilst there is some commonality to the issues in the lists, the emphasis tends to be on the negative side and their description probably reflects the deficiencies and difficulties within the organizations that produced them.
Analysis of the lists shows that the reasons for success and the causes of failure can all be grouped into one of John Adair's three elements: task, team, or individual. In projects that fail, one of these elements has been exaggerated at the expense of the other two. Alternatively, one has not been given sufficient attention. Despite this, the conclusion is that it is the basic task issues that are the main problem, which are primarily the project manager's responsibility.
I have been fortunate in that I have spent my hands‐on project management experience in organizations with a strong project‐management culture, namely, good corporate policies, management procedures, regular thorough reviews and having well‐developed systems, tools and techniques. There has always been a total commitment to project success of delivering the client's scope within cost and time targets with the right quality of performance and finally, having a happy client. My career, salary, and bonus depended on achieving these targets, and it was usually challenging, interesting, and fun. I have always regarded a strong project management culture as a prerequisite to success.
Research commissioned by the APM20 resulted in a report identifying five factors: “As a formula for success; get these right and the rest should follow”. Namely:
- Thorough project planning and review (interestingly this factor was least present in the projects surveyed)
- Clearly specified and recognised goals and objectives
- Effective governance with clear reporting and regular communication
- Project professionals forming a competent project team
- All parties involved must have commitment to project success.21
I think that it is fair to say that the APM research was dominated by systems and services – soft projects. My experience has been primarily physical and technological – hard projects. Now that I have an opportunity22 to review the APM results with my own experience, it is interesting to see the compelling correlation between them and identify that there is no difference between the success factors for soft or hard projects.
In looking at why some projects succeed and some fail, it is assumed that the prerequisites mentioned above, as well as all the basics, are in place. We know what we are supposed to be creating, by when, and for how much, and (if we are a contractor) we have a contract to do so approved by all the lawyers and senior managers and so on. But still, some go well (succeed) and some don't (fail). Why? What are the essential issues? My analysis in the remainder of this section is on trying to understand what is not usually covered elsewhere, namely the practicalities that shape and influence the achievement of the success factors. It is based on my experience as a hands‐on project manager and from what I have learnt as a consultant and from teaching project management, including ten years as director of a master's course.
1 The Project Management
1.1
The primary tool for project success is the project management itself. As already indicated in studying the literature on success and failure, all the failure elements are mostly down to how the project management was implemented.
- The secret to success of an organization is to break the project down and turn the processes into less‐complex types. That is, turn strangers into repeaters, turn repeaters into runners, and turn runners into routines. (See the beginning of Section A).
- As already mentioned, nobody manages a large project; you should manage a series of small projects. Use the product breakdown structure and delegate sections to different project leaders.
1.2
Each participating entity in the venture (owner, co‐owners, contractor, joint venture partners, etc.) must have a person or persons at board level nominated as a sponsor,23 who stay for the duration of the project. They must have a specific interest and knowledge of the work, and they must make a significant contribution to the success of the project.
1.3
The structure of the project management function can be a major contributing factor to project failure. At one extreme is a project manager reporting to a director of projects who is managing a complex organization. At the other extreme is a similar structure but, in addition, they are also reporting to a steering committee representing different organizations with different objectives as well as trying to get a user committee or handover board to agree amongst themselves. (See paragraphs 3.4 and 3.5, Involvement of Users, below.)
- “In the view of several of the Computerisation of PAYE's [COP] senior management, the Steering Committee was the single most important reason for the success of the project.”24 Until recently COP was the only large government information technology project that had been successful, due to the project manager and how he fulfilled the project management process.
- The complexity or the size of the client team influences the communication process and thus the chances of success. Further, some industries and businesses create really complex client/user – contractor interfaces.
- Do not underestimate the difficulty of the communication process between you, the contractor, and the client. Add to that the difficulty of communicating between the project manager and line management. Do not forget the interface between the project manager and the project team.
- Experience shows that relatively few businesses understand the roles and responsibilities within the matrix organization. Make sure that the functional managers fulfil their obligations, as part of the matrix organization and accept responsibility for the quality of the technology. Make use of the benefits of project audits.
- Once construction starts, the role of the project manager can become severely compromised (see Part IV, Section Q Installation & Construction, paragraph 4.2) since construction can take control by being in direct contact with the client. If the project manager wants to maintain control, then they must move to where the client is. This will mean leaving a deputy to finish off work in the home office.
1.4
Naturally, a key element is the project manager. The management style and competence of the project manager will have a big effect on how the team reacts to their leadership. The project manager must establish command and trust and inject energy and enthusiasm.
- Learn to manage upwards. Make sure that your boss clearly understands when you want help and when you do not want them to interfere.
- Don't hide problems. Tell your boss everything. If you don't, they will talk to their opposite number in the client organization and make decisions that you won't like, through lack of information.
- If personnel have to be removed, then so should the opposite number in the client team. This is particularly true of the project managers. Otherwise, if only one party is replaced, then the new person is always at a disadvantage.
- As stated in Section D The Project Management Role, paragraph 2.8.3, a project champion will be needed for internal projects.
1.5
Management may want to have people released for a new prospect or other reasons. Consequently, identify replacements and plan for the second‐in‐command to take over. If you want to move onwards and upwards, you had better have a fully trained deputy to take over (see Section D, paragraph 2.8.1).
2 Alignment of Objectives and Client‐Contractor Relations
2.1
A project that is a war zone will fail. Some conflict is inevitable since contractors and clients do not have common interests – not in the real world anyway. The contract hasn't been written yet that truly merges contractor and client interests. Nevertheless, it must be assumed that at the corporate level there is a common cause for the project to be a success.
2.2
At the project manager level, the client project manager has to demonstrate (to their superiors, of course) that he or she is being tough with the contractor and getting value for money. Conversely, the contractor has to demonstrate (to their superiors) that things are not being given away. However, this can be done professionally without endangering the relationship.
2.3
The project manager must develop a personal relationship with their opposite number. Similarly, the project manager's supervisor must establish a relationship with their opposite number in the client organization. At least at these levels, there can be a common objective to make the project a success. The client project manager is dependent on the contractor for their success, and the contractor needs the client for career enhancement and future business.
2.4
Most individuals will have hidden agendas. As already mentioned the personal objectives will always carry more weight because of the fact that they are in the control of the individual.
2.4.1
Pick a team where the individuals will fulfil their private agenda by completing a specific role or job within a successful project (see Part V, Section Q, subsection 1. Selecting the Team).
2.5
Be sure every team member understands and is committed to the project objectives.
2.6
See Part IV, Section E Client Relations.
3 Involvement of Users
3.1
The term user is usually utilized to identify the end‐user operators of a facility. However, the term can also be utilized to indicate the next party in the work process chain, who uses the work produced from the previous function. Thus, involvement of the users is necessary to get them to buy into what they will be taking over. For example, manufacturers and the construction people are the users of the design. It is, therefore, crucial that the construction manager is involved in the early design process. See Part IV, Section Q Installation & Construction, paragraph 1.3 and 1.3.1.
3.1.1
For prestigious building projects, the involvement of the users is achieved by having a design competition. The public is then invited to contribute their comments, or alternatively a consultation survey is carried out.
3.1.2
For infrastructure and development projects, it may be necessary to develop an ongoing relationship with the local community. Issue a regular newsletter to demonstrate that you are listening to their concerns.
3.2
Similarly, the commissioning team will need to be involved in the early design stages in order to explain the sequence in which the facility will be set to work.
3.3
Both types of user need to be involved in the early project formulation stage. Using/contracting another party or organization for the execution stage (as is customary) introduces a potential barrier to success.
3.4
For some types of projects (for example, information technology) it is sometimes necessary to create a user committee to represent the views of the various departments and functions that will be operating the system.
3.5
Similarly, for projects with multiple groups of end users, it is necessary to have a handover board made up of representatives from each group. This enables the project management function to defuse complaints from individuals.
3.6
The foregoing paragraphs address involving the users at a management level of the project process. However, the principle also applies at the designer/construction worker level. Problems occur because the person who designs or constructs an item only performs to meet the requirements of their particular task. They don't necessarily care about matching up with or fitting the subsequent step. We try to overcome this problem with combinations of work at the higher level (for example: design, supply, and fabricate; fabricate and install; design and build; and so on), but the problem still exists at the lower trade levels.
3.7
See Section F The Owner and Client, Paragraph 1.6. Also, Part III, Section B Contracting Strategy Considerations, paragraphs 5.7 and 5.13.
4 Get and Build the Right Team with Clear Roles and Responsibilities
4.1
Push for resources – get the right people. Build a team that has the skills, experience, and behaviours required for the job. Your success depends on the teamwork of the people you chose. Without the right people, it will be ten times more difficult.
4.2
The reality is that the functional managers will offload who they can. Get rid of the dead wood. The team must have mutual respect.
4.3
Roles and responsibilities must be clearly defined.
4.3.1
After you have chosen a key team member, explain (on a one‐to‐one basis) why they were chosen as the right person for the position. Clarify with them your and their understanding of the responsibilities of the role.
4.4
Explain to the individual what your expectations are of them in the project role.
4.5
Find the expert who is the key to the technological issues.
4.6
See Part V, Section Q for Selecting and Building the team. Also see Part IV, Section D, Mobilisation.
5 Clear and Complete Scope Definition
5.1
For internal projects, it is essential to get a clear brief at the start. Software projects need clarity of what is to be achieved. Physical projects need clear and complete scope definition.
5.2
As already stated The Business Round Table in the United States says that the poor definition of project scope is the primary cause of cost overruns.
5.3
Develop the scope using a product breakdown structure and work breakdown structure in a team process.
5.4
Specifications are difficult to write, and technical people need to improve their aptitude with words. Avoid the tendency to use generic language for descriptions. Be more specific. Do not use words that keep options open and allow for improvements as the project develops.
5.5
For clarity, use ‘negative specifications’ stating what is not included.
5.6
Know the scope of work, and be sure you have all the necessary information, materials, and tools.
5.7
See Part IV, Section F, Scope.
6 Thorough Planning of the Work
6.1
I now think that planning is the overall key to success (and the feasibility stage must be regarded as part of the planning process), firstly, because all the other aspects that I have listed could be said to be encompassed within the holistic concept of planning. Secondly, examination of the evidence indicates that projects that are extensively and thoroughly planned by having an extended planning phase usually start right. If a project starts right, it will more than likely continue successfully.
6.1.1
The Computerisation of PAYE project (mentined in 1.3.a above) carried out a pre‐feasibility as well as a full feasibility study that took over two and a half years to complete and ‘the feasibility plan contained an implementation plan of unusual detail’.
The Land Speed Record Thrust SSC project achieved its objective in one day but was planned for six years.
Sir Ranulph Fiennes' journey around the earth's polar axis, using only land transport, took three years but was planned for seven years.
6.1.2
The above projects should be contrasted with the United Kingdom's Nimrod Airborne Early Warning System, the AEW project of the 1980s which compromised the feasibility stages in order to save time and consequently was late, overran the budget, and was abandoned.
6.1.3
The problem for commercial projects is the conflict between spending time in the planning phases against the benefits and financial returns to be obtained by finishing earlier.
6.2
Nevertheless, the project manager must start out from the assumption that the plan produced in the initial (feasibility study or particularly the tender) stage may well contain dangerous nonsense.
6.3
A project, even at the proposal or feasibility stage, must be planned to a Level 3 network degree of detail.
6.4
Get buy‐in to an achievable end date. Review the schedule with all key members of the project team and obtain their agreement to it – preferably in writing. Get their commitment.
6.5
The tricky bit is how to amend the plan, realistically, to what everyone wants. Whatever is done must be written down and incorporated into the contract (and paid for!) – state that the schedule can be achieved, provided that such and such is done.
6.6
See Part IV, Section J, Planning and Scheduling.
7 Planning Communications
7.1
Surveys show that communication is the biggest problem in all organizations. This is because they have not been planned. A lawyer will treat an interaction with another party as a project, and they will plan their communication strategy.
7.2
Agree on how each communication mechanism will be used on the project.
7.3
Circulate information religiously and appropriately. Don't clog up people's in‐trays (real or virtual) with unnecessary documents.
7.4
See Part VI, Section A Communications and Section E Personal Skills.
8 The Efficiency of the Project Launch Phase
8.1
The challenge is to allow time for planning the launch phase so that overall time is saved. A well‐organized project management department will have developed a skeleton project launch programme (many of the issues during the launch phase are common to all projects) in order to save time.
8.2
Persuade the client to issue a letter of intent/instruction (see Part III Section F, Contracts, subsection 1 Starting work) that gives authorisation to initiate work and be paid for an agreed list of activities. The list should include pre‐ordering/reserving manufacturing capacity for long lead material and equipment items.
8.2.1
Ideally, use members from the winning proposal team to set up the infrastructure of the project whilst the project team is being mobilised.
8.3
Make maximum use of the team's initial motivation and enthusiasm.
8.4
Good team building should enable the straight line portion of the ‘progress’ curve to be achieved early.
8.5
If the launch phase is effective and efficient, there is a significantly greater chance that the following work will go according to plan.
8.6
Do not use up project float at the front‐end. Float is for when it is needed at the end of the project.
8.7
See Part IV, Section A, Project Launch.
9 Change Control
9.1
As already stated The Business Round Table in the United States says that the loss of control during design and execution is the second cause of project cost overruns.
9.2
Changes are inevitable. The business environment will change, and this will impact on the project. However, be rigorous about resisting ‘nice‐to‐have extras’ that were eliminated during the initial evaluation of the project's viability (see Section A, paragraph 1.5).
9.3
A rigorous and equitable change control procedure is essential for success.
9.3.1
‘The management team’s approach should be to discourage changes of any sort. Only alterations which are necessary for safety or to make the facility work or essential to facilitate construction should be agreed'.25 One should add: or which conflict with regulations.
9.3.2
‘The great emphasis on change control must be mentioned as key to the success of the Computerisation of PAYE project’.26
9.4
See Part IV, Section L, Variations/Changes/Claims.
10 Effective Decision Making
10.1
Project control is achieved by the decisions that the project manager makes.
10.2
Decision‐making involves experience and judgement together with pertinent and timely information. The experience and judgement is a function of the capability of the project manager, and the pertinent information will have been determined in setting up the project control system. The timely element is a function of the efficiency of the reporting system.
10.3
Timely information can be provided (to three decimal places!) by crunching mega quantities of data, using artificial intelligence (AI). Just don't lose sight of the rules of thumb that you should be familiar with, and apply to your particular technology.
10.4
An average decision well timed is better than a good decision badly timed.
11 Tackle Things Today – Tomorrow They Will Be Bigger
11.1
Chase progress relentlessly.
11.2
Check costs regularly.
12 Conclusions for Success
Success is the ability to go from failure to failure without losing your enthusiasm.
Winston Churchill
12.1
Understandably, we always know more in the future and are, therefore, more often than not perceived to have failed. Consequently, start promoting the success of the project right from the start of the project. Publicise successful milestone achievements.
12.2
We can deduce from all of the above that project management is a demanding discipline. Putting all people's success and failure lists together; we would find that the final compilation would include every aspect of project management. Consequently, if you fail in any aspect, the project is likely to fail. Conversely, to succeed, you have to do everything right!