Some Project Management Tips
- Details
- Category: Functions
- Created on 10 April 2013
- Written by Steve Burrows
A little while back I was chatting with a director of a large business who bemoaned the record of the business in delivering projects successfully - on time, within budget etc. It became obvious that the business's project managers were not very experienced, and if they were going 'by the book' they were probably bound to fail. The reality of projects is that whilst a good project management training course can teach you the rules and processes for a particular project management method (such as PRINCE2), no training course can teach you how to make a project actually work, because project management methods are about process and governance, not people and outcomes.
A properly applied good governance regime can identify project plan deviations soon after they happen, giving the project manager the opportunity to prevent the project from spiralling out of control, but it will never be a method of guaranteeing that the project outcomes are as desired, or that the project manager can effectively prevent or correct deviations. What is needed in order to deliver projects successfully is a laser-like focus on outcomes, the leadership skills to ensure that all team members fulfil their responsibilities, and a deep understanding of what may go wrong. With these in mind I gave a one-day seminar to the business's project managers which can be very briefly summarised as follows. These are the bits you need to understand and control to deliver a project successfully:
Deliverables vs. Outcomes, Intent vs Specification
No project exists to produce deliverables, we enter into projects to achieve outcomes, outcome is 90%+ of what matters. The goal of a project is not to produce the products (outputs) defined in specifications, but to deliver the intent of the project originator(s). The project manager must understand and subscribe to delivering the intended outcomes of the project, these are all that matter and everything else is negotiable.
Stakeholders & Stakeholder Relations & Stakeholder Involvement
With intent and outcome in mind, the successful project achieves the aims of the originator - the primary stakeholder. Every project requires the engagement of multiple stakeholders who will either either provide leadership, enablement or barriers. If you lose the engagement of stakeholders the project will fail, it will not deliver what the originator wanted. Possibly the biggest responsibility of the project manager is to keep the stakeholders close and engaged throughout the project, whether they want to be or not.
Planning & Budgeting (the "MS Project" bit)
Most project plans are nothing more than a Gant chart. They look nice but have no substance. The toughest part of running a project is discovering and controlling the barriers to success - success being delivery of the outcomes the originator wanted in the time needed and the cost provided for. The project plan should have detailed, costed and agreed allocation of all resources involved; our people, external contributors, things we must buy in etc. Every element of work must be captured in the plan, every piece of work should have a realistic estimate of the effort involved allocated to the people who will be doing it (including their costs) and when (including allowance for their holidays and other commitments) - every activity or input to the project should be recorded in the plan. This tedious process is not about working out a best case timescale, it is about discovering the barriers to achieving success and committing the involvement of everyone involved. Without a detailed plan, which will probably take man-weeks of work to finalise, the project will fail. It will take too long, it will cost too much, it will not be a contract between the project manager and the delivery teams. Hope is not a strategy for project success.
Project lifecycle - not Specification to Delivery but Pre-Concept to End of Life
In constructing the plan it is necessary to understand that the start of the project is not the start of the project, and the end is not the end!
Almost all projects formally start with a go / no-go decision from the project originator / sponsor / board - based on the plan and the effort, time and costs it reveals. That is not the start of the project, a project starts, and starts incurring costs, when the "MAN" (money, authority, need) has and Idea and says "I want X", or "We need to do Y" - that is the start. Each project has a pre-concept phase (build and explore the bones of an idea), a concept phase (put the flesh on the idea, develop proper specifications of desired outcomes etc.) and a pre-project phase (plan the project). If any of these are neglected the project will probably fail, either by not delivering the required outcome or by costing too much and/or taking too long.
Projects are generally accepted as finishing when they deliver 'products' - however this is not the end. The products or deliverables will need maintaining, they will be expected to exist and to continue achieving the desired outcomes for a finite time into the future - until end of life (EOL). This post delivery phase is as much part of the project as the effort to achieve delivery. If we construct a bridge across a river the desired outcome was not constructing a bridge, it was people crossing the river - perhaps for one day, more likely for 100 years. Delivery of the project is not the end, it is the start of the process of achieving the outcomes for which the project was initiated and if it fails to deliver those outcomes the project will have failed. Don't make the mistake of Iraq, plan the post-delivery phase from the start of the project, again including costs and resources. Delivery of the project is merely a step along the path to achieving the intended outcomes.
Understanding the full project lifecycle is also necessary to understand TCP (total cost of project). TCP can be bitter medicine, but it is best understood and taken up front.
QCDs - Quality, Cost, Delivery, the three variables of project control
Once a project is running things will deviate from plan (a.k.a 'go wrong'). Pretty much every project deviates from plan, however hard you have worked at the planning and budgeting stage, and however strong the commitments from participants, something will go awry. When it does you have three options - increase cost (effort and inputs), delay delivery (increase time), or reduce quality (quality is not some arbitrary subjective judgement, it describes the features / qualities of the project's products). Acknowledging that at least one of these will be stressed during the project the sensible project manager will build in contingency, most likely in the form of extra cost estimate, extra time estimate, and 'nice to have' features which can be dropped / deferred if necessary. The successful project manager guards his QCDs like a Rottweiler, without control over the QCDs the project manager ultimately has no control at all.
Dynamic Risk Management & Scope Creep
Having developed a robust plan and budget, and established that the variables in a running project are the QCDs, the biggest challenge is managing risk. There are innumerable risks in most projects - planning and estimating inadequacies, input failures (resource and supplier problems), and quality deviations. The successful project manager mitigates all three in the planning stage by building in contingency, but mitigation alone does not ensure success. The progress of a project must be continually monitored to detect deviations as soon as possible before they run out of control. The inevitable demands to "add in this feature" must be resisted and deferred (to "phase two") unless the feature is essential to achieving the intended outcome. Once a project is running the adding in of 'nice to have' features is a luxury the project manager can only afford if he is on-track, ahead of time, under budget, and genuinely thinks that the additional feature can be achieved within the planned contingencies. If the project runs late or over-budget due to unplanned additions it will be a failure, the project originator, sponsors, team and all stakeholders will remember that the project was late and over budget, not that the Managing Director demanded extra features mid-project. The project manager must both push the team forward to prevent slippage, and push away all those who would interfere with the delivery of the original plan.
Measuring Progress, Reporting & Negotiation
Risk management and mitigation necessitates that the project manager becomes aware of a risk as soon as possible, preferably while there is the opportunity to forestall it. In order to do so he must keep close to the teams delivering the project's products, and regularly test them about progress. Most delivery teams, whether they are IT developers or construction site workers, become aware of potential threats to the schedule very early - if they care. If they don't care then it is very difficult for the project manager to become aware of the emerging threats to a project in time. The first and most important action in measuring progress is to ensure that delivery teams are committed to the plan, that they share the plan and measure and report their own progress against the plan. The project manager should have a regular and frequent reporting session with delivery team leaders to discuss progress, threats, concerns etc, at which the delivery team leaders will voluntarily disclose their problems ("barriers") in order to seek help so that they can remain on schedule and avoid letting the others down or being the weak link in a project. The good project manager does not measure progress, the delivery teams do that, the project manager provides the forum to share, record and escalate progress, and to expose the current barriers to success. Obviously progress should be recorded against the plan, and reported regularly to all stakeholders whether the news is good or bad. More importantly, all potential risks and barriers should be exposed as soon as possible and then either resolved as a project team, or by the project manager, or escalated to the project sponsors as appropriate. When risks occur that threaten the plan the first priority of the project manager is to negotiate his way out of those threats, to ensure that agreed QCDs will be achieved - even if that means renegotiating the QCDs. In practice in most situations the original QCDs can be preserved, but only if the project manager can negotiate. Negotiation is a key skill for effective project managers.
Keeping on Track
Keeping on track is largely about foreseeing risks and forestalling them. If the project manager fails to spot a risk before it occurs then the project is going to go off track, the only variable is by how much. Having foreseen a risk in good time the questions are simple - what is the impact, does it threaten the QCDs, and how can it be avoided or mitigated? The impact may be minimal, and if the project plan contains appropriate contingency so that the QCDs are not threatened the project manager may simply choose to accept the impact, but in general risks should be avoided or mitigated, a risk usually implies erosion of contingency such that cost or delivery are increased even if they remain within the bounds of the project plan. Keeping on track is ultimately very simple, a combination of proper planning (see above) to minimise the potential surprises in a project, and diligent and frequent measurement of progress, exposure of barriers, and negotiation where necessary. The secret to keeping a project on track is, unsurprisingly, to ensure that it doesn't get (the opportunity) to come off the rails in the first place. Prevention is always better than cure.
Getting Back on Track
This is where the project manager earns his kudos, the big bucks etc., right? Wrong. Getting back on track means only one thing, someone has failed. The only time a project manager deserves kudos for getting back on track is when he's been parachuted in mid-project to clean up the other guy's mess. I said earlier that negotiation is a key skill for project managers, it is the key skill for project recovery. Project recovery means that either the project plan or the QCDs need to be renegotiated, start with the plan. As soon as we decide that a project is in need or recovery, it is off track, then it has implicitly failed. The old project plan doesn't work and the project manager must discard any psychological attachment to it. A new plan is required and must be devised that will bring the project back on track, it may contain few or many elements of the unexpired part of the old plan, but the first job is to develop a new plan, by negotiating with all the delivery team leaders and external suppliers. It may be necessary to change delivery teams and / or suppliers. There may be perceptions of contractual commitments to external suppliers, these should not be perceived as offering them any real protection, the project has failed therefore they have failed and the project manager should not accept any boundaries to renegotiation, the objective is to ensure a successful outcome for all parties, and success is measured according to delivery of the project to achieve its desired outcomes. If it is not possible for the best new plan to get the project back on track then the project manager must negotiate with the primary stakeholders to alter the QCDs with minimum damage to the desired outcomes and intent, which means going to the project originator, being entirely open and honest about the situation, jointly considering the replanning options, and jointly agreeing what variance to the QCDs can be accepted while achieving the original aims of the project. Getting back on track is hard, and the project manager must be a hard negotiator, other participants in the project have failed and in doing so have failed the whole project team, being gentle is not an option.
Problem Solving Process
A quick aside, projects are made up of groups of people or teams contributing to a common objective. All projects hit problems. In order to resolve problems it is usually necessary to involve multiple project contributors. Leaving the solving of a problem to one delivery team, supplier or contributor is usually a mistake, and so it is useful for the project manager to have team-working tools and methods in his armory. The most important is the Problem Solving Process. There are many versions of a Problem Solving Process embodied in different team-working methods, the generic six-step wheel is as good as any, the project manager should know how to use it and lead other contributors through the cycle as a group so that problems are solved jointly and collaboratively.
Multi-Level Projects (a.k.a Programmes) & Programme Management
Complex projects are..... complex. An important part of the project manager's role is to minimise complexity, complexity introduces confusion and risk. When creating a project plan it should be possible, and best practice, to divide it into independent sections. For instance the project plan may include software development, user training, roll out. Where practicable it is sensible to separate these element out into "sub-plans", creating a hierarchical project plan in which the overall project is the "A level" schedule, and contains several "B-level" schedules (which may in turn contain "C-level" schedules and so on). Where possible this should be done. A project plan should be easy and simple to grasp, but in the case of complex projects this is not possible so it should be divided up into bite-sized chunks which can each be seen as a mini-project and managed semi-independently. For some bizarre reason this nested approach to project management is not common, most project managers try to manage too much complexity in a project instead of breaking it down into chunks, which may all be managed by the same project manager, resulting in project management oversights simply because the dependencies become too complex. The nested or hierarchical project is normally referred to as a multi-level project. If we want to be grandiose we call it a programme, which is nothing more than a collection of inter-related projects, and aggrandise the senior project manager's role with the title of "Programme Manager". Usually when we do this the first thing the Programme Manager does is to say he needs project managers working under him to manage the individual projects, so I prefer to keep the view that multi-level projects are just that, projects, and avoid introducing the term "programme", otherwise the programme manager merely becomes a parasitic manager of multiple project managers.
People & Culture vs Technology, "wetware", why the soft side is 80% of the problem
Most of what I've written above is applicable to pretty much any type of project, but a lot of my own background is running projects that involve technology. So here is one simple point, there is no such thing as a technology project. People commission projects, including projects to develop technology, to achieve outcomes. Those outcomes either directly or eventually impact people. People use technology, hopefully they benefit from technology, but whether they adopt the technological products of a project or not is up to them, their behaviours, their culture. In short all projects are ultimately people projects - there is no point in building a bridge across a river unless people will use it to cross the river. Whether a project succeeds or fails in achieving the intent and outcomes for which it was established is entirely people dependent. In the computing business we have, and most people have heard of them, "software" and "hardware". Less commonly known are the terms "vapour ware" - which means something conceptual but not yet demonstrated as a reality, and "wetware". Wetware is you, me, anyone who might interact with the project or its products. A project's success is determined entirely by wetware, we can design and build the most wonderful computer, car, smartphone.. whatever, but however technically sophisticated it will not be a success unless people adopt it, and ultimately most of the problems in both creation and adoption will be due to people. Therefore the wetware should be the single biggest worry for a project manager, and if asked why a project / product etc. is not performing as hoped, the answer "it's the wetware, stupid" will most likely be the most valid response.
Change Management, what it is and why it's essential
So, people are the problem, the wetware. At some point in a project the big issues will be about people, guaranteed. Why? It's very simple, for our project to succeed, to make things better, to sell more widgets, whatever, people will have to change. They will have to change how they work to adopt a new "more efficient" method or process. They will have to learn to use a new machine or gadget that works differently to whatever they used for similar purpose before. They will have to learn new skills and change old ways. As I said at the beginning the successful project is not about delivering "products", it is about "outcomes". Our shiny new product, system, building, bridge, whatever, is worthless unless people adopt it and use it. A project is not complete without consideration of how we get people to change, and this is generally called Change Management. Very simply, your project will fail (to achieve its desired outcome) unless it incorporates the change management element that will encourage and equip people to use its products. When reviewing your project plan you should ask, "OK, we know how to make / deliver it, now how do we plan to get people to use / buy it?". The answer may be simple or complex, all depends on the circumstances, but a project plan that doesn't address the change management element that will encourage and enable people to benefit from the project is no better than a lottery ticket. It's like the Iraq War - the West won, now what? As history has already recorded, the Western allies who won the Iraq War had no plan in place to look after Iraq and its people once Saddam Hussein was removed from power, they had no change management plan, and so a decade later the allies and the Iraqi people alike are still coping with the consequences of "success". Change management is essential in every project, no project plan is complete without it.
Change Leadership, why Change Management is a false god; how to deliver projects that actually work
I heartily dislike the term "Change Management", because it implies that people's behaviours, values, motivations etc. can be changed in a mechanistic way. So while our project plan should include change management as mentioned above, the project manager needs to understand that change management does not deliver change! It merely provides the space where change will be delivered, it is very rare that you can programmatically drive a change in people's behavior. So how do we get people to change? Very simple, Leadership. People change because they are pointed (directed) in a new direction, or follow (the leader) in a new direction. Change without leadership is chaos or anarchy, therefore the change management part of a project is the space in which the people impacted by the project will be guided to the new future. However all-powerful the project manager may be he cannot force or drive people to change their beliefs, their values, their culture, and the working practices and methods which follow from these, so there's no point in trying. Millenia of leadership evolution have proven this to be true, achieving change is a hearts and minds job, people must either follow the leader down the new path, or go down it because they believe in him, so while the process of achieving successful adoption of the project's products by the wetware may be described as change management in the project plan, success is delivered through leadership. The project manager should not be seduced into thinking that change is something they can prescribe by writing it into the plan, it needs to be there, but in reality the change, which is what makes the whole project successful and worthwhile, will be delivered through leadership of the people whom the project's products are intended to serve. Change management is merely creating a space in the plan for leadership.
Here endeth the lesson.
Comments
RSS feed for comments to this post