WHY PROJECTS FAIL
#1 – Scope Creep
Scope is everything that you are going to do and conversely, not going to do. So once you’ve figured out exactly what the project work is, usually via a Work Breakdown Structure, you need to freeze it and zealously guard against unplanned changes to it. So planned changes via a change control board are ok, since then the PM can issue a new schedule, risk and budget plan as needed. Otherwise, you will surely miss your target and make both the management and customer unhappy.
#2 – Overallocated Resources
Often there are too few resources working on too many projects at the same time. In conjunction with that, managers don’t seem to have a grip on what their resources are doing all the time. Team members are left to figure out for themselves what projects they should be working on and when. Better is for managers to meet weekly to discuss resource usage perhaps using a spreadsheet to track.
#3 – Poor Communications
Many people on a project will know the project manager only through his or her communications. And they will know them by how their voice comes across over the phone or especially by how well-written their emails are. If the project manager is not a clear unambiguous communicator, chaos and confusion will ensue.
#4 –Bad Stakeholder Management
Stakeholders have a vested interest in the project for the good or sometimes to the detriment of the project. It is the project manager’s job not only to identify all stakeholders, but know how to manage and communicate with them in a timely fashion. A communication management plan helps here.
#5 – Unreliable Estimates
Estimates are very often just guesstimates by team members who are trying to calculate duration of tasks based on how long it took them last time. This may turn out to be totally accurate or may be completely wrong. And if wrong, leads to a flawed schedule and increased risk. Historical records kept between projects helps solve this.
#6 – No Risk Management
Every project is unique and hence, has uncertainty. When we try to qualify and quantify that uncertainty, we call it risk. It is incumbent upon the project manager to proactively anticipate things that might go wrong. Once he has identified risks, then he and the team can decide on how to respond to (e.g., mitigate, avoid) those specific risks should they occur.
#7 – Unsupported Project Culture
I was once asked to consult for a company and discovered that a complex project was being handled by an untrained secretary using 20 Excel spreadsheets. In this case, management clearly did not fully understand what it took to manage a project either in tools or using trained personnel. This is not easily solvable because it requires education of management and a cultural shift.
#8 – The Accidental Project Manager
This is similar to but not exactly the same as the unsupported project culture. In this instance, what typically happens is that a technical person (software developer, chemist, etc.) succeeds at the job. Based on that, gets promoted to project manager and is asked to manage the types of projects they just came from. The problem is they often don’t get training in project management and may well lack the social skills the job calls for. And so they flounder and often fail despite previous successes.
#9 – Lack of Team Planning Sessions
There is no more effective way to kick off a meeting than to have the entire team come together for a planning session. This enables everyone to not only work together on project artifacts (schedule, WBS) but also to bond as a team and buy into the project.
#10 – Monitoring and Controlling
Many project managers will create a schedule and never (or rarely) update it. Or if they do, they’ll just fill in percent done, which is an arbitrary number often picked out of the air by the team member. Better if they record actuals such as date started, work accomplished and estimate of remaining work.
DIAGNOSIS: SEVEN PROJECT PERFORMANCE FACTORS
Does the focus on business value, or technical detail?
This involves establishing a clear link between the project and the organizations key strategic practices. The project plan needs to cover the planned delivery, the business change required and the means of benefits realization.
Case Study: I have seen projects fail were time is spent myopically on the detail of an issue, often a supplier contract issue, and not the overall purpose eg to produce an ROI of 8% in 3 years. In some cases we would be wise to pivot, take a new approach, rather than get bogged down. The effect of not doing so is to delay delivery of a function or feature with a disproportional consequential impact on the people and overall programme. Projects seldom operate in isolation and problems in one inevitably impact upon others and/or business as usual.
Is there clear accountability for measured results?
There must be clear view of the inter-dependencies between the projects, the benefits, and the criteria against which success will be judged. It is necessary to establish a reasonably stable requirement baseline before any other work goes forward. Requirements may still continue to creep. In virtually all projects there will be some degree of “learning what the requirements really are” while building the project product.
Case Study: I have experienced situations where incentives, rewards, and punishments tear people apart by pulling in different directions. Typically the tug between projects and business as usual means compromises for both, or outright failure of one because of another. There needs to be a relentless review of: What is it we are trying to achieve here? And a clear focus on output or outcome measures on the agreed dials: Does this move the needle in the right direction?. If we simply congratulate ourselves on effort and not outcome we risk the trials of Sisyphus and burnout [Sisyphus -was punished by being forced to roll an immense boulder up a hill only for it to roll down every time.]
Is there a consistent processes for managing unambiguous checkpoints?
Successful large projects typically have software measurement programs for capturing productivity and quality historical data that can be sued to compare it against similar projects in order to judge the validity of schedules, costs, quality, and other project related factors. The lack of effective quality centered mechanisms can be a major contributor to both cost and schedule overruns.
Case Study: I have seen suppliers argue that there is no problem with being 20 days late with Phase A because Workstream B is 20 days ahead of schedule. This is misdirection. Generally of a project is late it will only get later! If your track record is 20% late then the probability of recovering that time is low unless there is a clear understanding of cause and an intervention of consequence. My own experience is that projects seldom improve productivity and instead cut scope or quality to recover lateness. In one example comprehensive testing was compromised to random sample testing in order to gain pace, but inevitably the hope-value (that everything will be ok) did not pay-off. These compromises generally creates further problems later with consequential impact on cost.
Is there a consistent methodology for planning and executing projects?
There should be a detailed plan developed before any release date of a project is announced. Inadequate planning is one of the major reasons why projects spin out of control.
Case Study: I am a fan of both waterfall and agile projects and both PRINCE2 and scrum have their benefits. For well understood projects, processes or services which are repeated with precision the waterfall approach is appropriate and time spent on designing the ginger-bread cutter [process and plans] is worthwhile when churning out products and services that conform exactly to a well prepared plan. However many are low volume, unique or ambiguous and in these contexts agile / scrum may be better, evolving, innovating, developing and improving as things progress. There is real merit in both but I have seen success and failure in mixing the two into Waterfall: Thinking and planning before doing is good. Scrum: Leaning, developing and innovating is good. waterfall + scrum = scrummerfall. Some scrummerfall approaches are like a series of small waterfall projects linked together, ostensibly as phases or stages of a later mission. However problems occur when you are managing plans, budget, delivery to a waterfall (PRINCE2) standard [like a bus on a route], but the activity is agile (scrum) [like an explorer on a bike].
Do you include customer at the beginning of the project and continually involve the customer as things change ?
It has been observed that successful projects occur when end users (customers) and the project members work as teams in the same cubicle, although this is not always possible. Projects are less likely to fail if there are informed customers giving meaningful input during every phase of requirements elicitation, product description and implementation. The customer needs to be asking, “how are the project result used over time and what do I get out of the results?
Case Study: I have seen projects lead by the IT department either because the customer has abrogated their responsibility or because the IT department feels that they have a better understanding of the customer needs, wants and expectations than the customer. A doctor will consult a patient before, during and after prescription. They may be expert, but neither the physician or patient will think it wise to proceed without some mutual understanding and consensus. Inevitably the communication gap brings frustration and can lead to "failure", whether real or perceived, the problem being that each may have a different criteria for success or failure.
Do you motivate people so that project efforts will experience a zone of optimal performance throughout its life?
This involves managing and retaining the most highly skilled and productive people. Knowledge is money. A project team made up of higher paid people with the right specialized skills is worth more per dollar than a group of lower cost people who need weeks or months of training before they can start to be productive.
Case Study: I have always believed that projects should be delivered on-time, on-budget, to-specification, but also develop the participants to be competent, capable, with drive and desire. So creating, nurturing and supporting the team is often as important (and frequently more important) than one project. Because a competent, capable, team with drive and desire can do so much more than one project! There can be problems however if the team is regarded as a component, like paint rather than an artist. When people are dropped in or pulled out they become ingredients and their collective skills, expertise and experience is wasted. I have seen projects that simply swap people in or out based on availability rather than their value to the team.
Do you provide the project team members the tools and techniques the need to produce consistently successful projects?
The project team must be skilled and experienced with clear defined roles and responsibilities. If not, there must be access to expertise which can benefit those fulfilling the requisite roles.
Case Study: I have seen organisations spend millions on supplier agreements and then scrimp on the training and development of the teams who will deliver a project. That's like buying a Formula 1 car and than expecting a bunch of people to manage, maintain and drive that car without the training and development that is necessary. They then wonder why their Formula 1 investment is not achieving Grand Prix performance.
ELBEIK AND THOMAS’S SUCCESSFUL PROJECT REQUIREMENTS
By speaking to experienced project managers Sam Elbeik and Mark Thomas attempted to identify the critical factors that must be addressed if a project is to be completed successfully. They developed a six stage process for managing projects namely: define, plan, build the team, lead and motivate, control communications, review.
Key success factors in rank order
- Clearly defined objectives
- Good planning and control methods
- Good quality of project managers
- Good management support
- Enough time and resources
- Commitment by all
- High user involvement
- Good communication
- Good project organisation and structure
- Being able to stop a project
Tim HJ Rogers MBA CITP PROJECTS, PROGRAMMES and CHANGE / CONSULTANT MENTOR COACH Adapt Consulting Company Consult CoCreate Deliver Mob +447797762051 Tim@AdaptConsultingCompany.com Tim Rogers is an experienced Project and Change Leader. He is founder of ciChange.org and curator for TEDxStHelier.Com . Roles have included Programme Manager for the incorporation of Ports and Jersey, and Jersey Post, as well as Operations Change and Sales Support for RBSI/NatWest. He is also Commonwealth Triathlete and World Championships Rower. He has a passion for learning and has been a Tutor/Mentor for the Chartered Management Institute. He is a Chartered Member of the British Computer Society, has an MBA (Management Consultancy) and is both a PRINCE2 and Change Management Practitioner.
No comments:
Post a Comment