Wednesday, 14 January 2009

The Titanic Sails at Dawn!

That line, from Bob Dylan's Desolation Row, is for me the best succinct definition of hubris there is. And hubris is the cause of an awful lot of project failures. Here are a few forms of hubris, and pride before a fall, that you will probably recognise.

'See the conquering hero comes'

When the project manager, and often many of the same team, come to a new project fresh from one that was recognised as a great success, they are given the benefit of the doubt, and questioned and monitored less vigorously, than lesser mortals. They themselves usually believe that their success is at least as much due to their skills as to chance or any other factor. The problem is that success with one project does not guarantee success with an entirely different one. That's not to say that good project managers don't perform better than average or poor ones, but that they are still fallible. In fact, they may be too cocky for their own good!

Everyone makes mistakes, and projects are full of uncertainties that need decisions. The temptation to believe that the successful project manager's decisions ought to be right, and the work of the team the best way to proceed, can lead to things not being properly and objectively evaluated. By the time it becomes clear that mistakes were made, a lot of time and treasure can have been wasted. The moral is: have the same, effective monitoring and evaluation procedures for every project, and apply them the same way every time.

'Never mind the quality, feel the width'

There are four constraints affecting every project: time, budget, scope and quality. Many projects have a greater emphasis on one, and that can lead to disaster as the others are forgotten. A project designed to accommodate a forthcoming legislation change will be seen as having the deadline as most important – the organisation cannot break the law -, and maybe cost is not a factor because there is no choice about the project. But costs still need to be controlled, the scope of the project needs to be maintained, and above all the quality, that is the fitness for the intended purpose should not be compromised. A bit pointless to deliver on time, if the project does not deliver compliance with the law, for example. A good example is the Millennium Dome fiasco, where the obsession with meeting the deadline meant that the project completely lost touch with its purpose: to create an attraction that people would want to visit. On time, but still an enormous and overwhelming failure on every other count.

Penny pinching to meet the budget at the expense of the project quality is another serious error, that is repeated far too often. If lack of money impacts on delivery dates, the project usually ends up costing even more, in direct and opportunity costs, and is still late as well.

The usual solution is to preview and test the effects of changes affecting the constraints, with the project sponsors when planning the project. What is the relative importance of the constraints, which can be allowed some slippage if essential to comply with the others, what scope can be removed, what objectives can be eliminated or postponed to another project? Knowing the priorities enables the project team to deal with problems early, and appropriately. If they know that budget is more important than scope, if estimates were wrong, or circumstances change, they can work out sensible actions to propose.

'Wishing and hoping, and hoping and wishing'

All too often, some problems are just left to the end. A lot of wishing and hoping that events will not happen, or solutions to problems will somehow turn up, or the supplier will actually be able to perform the essential miracle in time, and it will be all right on the night. 'After all, we are professionals, and know what we're doing.' Never happens.

The commonest situation is that slippage on times and milestones reduces the time for thorough testing, especially with IT and construction projects, and the project team hoping and wishing that there will be no last minute bugs and snags that they hadn't discovered. There always are.

An example is Heathrow Terminal 5, where the project team clearly hoped that the limited testing they had done could be scaled up to full operation in one go, without any problems. We know what happened. Not enough car park spaces for the workers, so many were very late; too many people not adequately briefed; no contingency plans for the volume of staff not present; no testing of the effectiveness of the equipment under sustained heavy load. And so on, and so on.

The fundamental rule is: if something has not been fully tested for real life, it does not work. Compromising on testing is compromising on success. And as a project manager, if you are going to go live with a big bang, rather than piloting and incremental delivery, ensure you are wealthy enough never to have to work again.

In conclusion, never trust yourself, your project team, your sponsor, or the world outside,and do not rely on the past as a guide to the present. Check, evaluate, test.

Tuesday, 13 January 2009

Why does change fail?

Successfully bringing about worthwhile change, irrespective of the size and extent, is often extremely difficult. In fact, some research suggests over 80% of business transformations fail.

Change is imperative: whether driven by market forces, the state of the economy, government legislation and direction, newly available technology, or the need for growth, no organisation can stand still.

There are many causes of failing to achieve the expected outcome from a change plan. The bigger the change, the more problems that can occur.

The common causes of failure can be grouped into four categories: failing to define strategic objectives properly, failing to relate actions to those objectives, failure to deliver projects satisfactorily, and failure to manage the people issue. Even a single project should relate to a strategic objective, even if that objective is simply survival or to stay within legal obligations. The following diagram illustrates the stages of a major transformation; at each step, things can begin to go wrong. The diagram illustrates the descending connection from Strategic Objective to Implementation. Each lower level must be clearly and directly related to achieving the objectives of the higher level: for example, no projects should exist that are not part of a programme, which is part of an action plan which is designed to deliver a strategic objective.

What should be done?

Firstly, the people and processes are the framework within which all change planning has to take place. Without the right people being available, adequately involved and concerned, supported by processes for change (as opposed to processes for business as normal), no transformation can be carried out effectively, if at all. There is no point in developing a strategic objective that can never be delivered. For example, if the objective requires skills the organisation does not have in its work force and cannot easily acquire, or will require things outside its workforce's job descriptions, or believes that it has the power to bring about change merely by demanding it, failure beckons.Strategic Objectives should be clear, unambiguous, agreed, achievable and of course resourced. If different people have different understandings of what an objective means, it will never be accomplished. Each objective should be expressed succinctly, and be defined wherever possible with measures, so that everyone can see how it has been met. Vague or unmeasurable wishes are not realisable objectives.

Whilst imposing objectives from on high can sometimes work, better results occur if everyone affected is committed and understands what the objectives actually are and why they matter. This requires communication and explanation to obtain agreement.

Objectives

Each Objective must be capable of being delivered. There is little point in aiming for things than cannot be achieved in the timescale, or at all. Over ambition, objectives that depend on factors outside the organisation’s control, and objectives that far exceed previous achievements are unlikely to succeed. Times and milestones should be realistic, and recognise dependencies properly.

Adequate resources must be made available: finance as required, appropriate skills and expertise, and enough time and people. There is little point in willing the end without also willing the means.

Each Objective must have clearly defined, evaluated and quantified benefits to be realised by achieving the Objective: what is the point of doing anything if there is no clear benefit from it?

Action Plans

Each Action Plan should be clearly connected to one or more strategic objectives. Some research suggests that about 40% of action plans are not related to any objective at all. Creating effective and deliverable plans is not easy, but failing to do so is the commonest cause of failing to achieve the objectives. Comprehensive planning is critical. There should be a comprehensive and comprehensible definition of the benefits expected from the Action plan, that directly come from the Strategic Objective definition.

Programmes

Each Programme should be designed to deliver one or more action plans, and be connected and achievable. Ideally, each programme should be organised around related objectives and activities, and consist of projects that can be planned and delivered. There should always be a clear end state that a programme should deliver.

Projects

Every Project should be defined and capable of delivery. The business needs and requirements should be enabled by Information Technology and the Internet where appropriate. Each person involved in each project should understand their role in the work and the project development process. Extensive planning is essential, and should be connected to the overall programme plans where relevant.

People

All change and every step are dependent on People: those who are carrying out the change, and most importantly, those affected by it. Every change ultimately depends on all the people involved not only understanding and accepting the change, but being enabled by appropriate process and tools to deliver. Many change programmes ultimately fail because the needs and views of the people at the end of the line: those facing the customer, making the product or delivering the service, were not properly considered, and processes not redesigned as needed.

Change is essential and unavoidable. It involves effort, and risks. To achieve the benefits change must be properly planned, designed and executed: there are no short cuts.

Some ideas that can help

Planning:

Inadequate initial planning of actions, programmes, projects, can often doom an entire change plan from the start. Whilst the desire to start and get some quick wins is reasonable enough, planning comprehensively from the start is imperative. And plans must be kept up to date - regularly revised in the light of new circumstances, and as each part is delivered.

Monitoring:

the need for effective monitoring of progress throughout is essential. And monitoring does not mean just creating or receiving reports, it means taking action and making decisions. If progress is not maintained as planned, the reasons should be found, the effects identified and corrective action taken - as soon as possible.

Communicating:

Failure to communicate with key stakeholders - regularly, comprehensively, clearly - will inevitably lead to problems. No-one will feel involved, or become committed, if they don’t know what is happening. This also means listening as well as telling!

Structure:

The application of structured methodologies, such as Prince2 for projects and MSP (Managing Successful Programmes) at the very least will provide checklists and some ideas of best practice. They are not an answer, but they are a guide, and because they are well established, many people will already know them. They also help everyone involved understand their roles and what is expected of them.

Benefits:

Throughout the entire change and transformation exercise, the benefits must be managed, and individual, named people made responsible and accountable for realising them. Losing sight of the benefits is the commonest cause of ultimate change failure: even if the changes have been implemented on time and to budget, if the benefits are not realised the whole exercise was pointless. As a quick reality check, every benefit defined as part of a project plan should also appear as a benefit of the programme, the action plan, and the strategic objectives. If it does not, there may be a problem, although sometimes there are subsidiary benefits from aspects of a project that are not part of its purpose or justification. The reverse is imperative: every strategic objective benefit must appear in at least one project as well.


Sunday, 14 December 2008

Enablement: more than just empowerment

The difficulty with the use of empowerment as a concept is that it too often becomes restricted to the area of authority, that is to say the giving of power, rather than the wider context of achievement. For that reason, I prefer to use the term enablement, because that can be more than merely power, but include all the aspects involved in improvement, achievement, skills and success.

Apart from the strategic, goal setting and leadership aspects, management is about delivering, which in turn is dependent on other staff. Good management is about developing, encouraging and increasing the skills of the staff being managed. The better staff perform, the better the manager performs. Enabling staff to give of their best involves several factors. This check list may help managers, especially those new to people management, ensure they succeed in their job by enabling their staff to succeed in theirs.

Delegate outcomes not tasks: see the earlier post on delegation. Allowing staff to work out their own way of achieving the objectives you set them – with support – increase skills, confidence and ability across the board.

Ensure people have the resources they need to do their jobs. This is not only adequate budgets and staff, but access to you and others for advice and help when needed, facilities such as office, equipment, and specialists.

Give them the authority to command the resources they are given: if they need to hire people, they must have the power to select, and to decide on terms etc (within corporate guidelines), and the power to spend their budgets.

Share your skills and knowledge: mentor, coach and support people. A good manager is not threatened by his or her staff being progressively skilled in what they themselves do.

Learn from your people: they will bring different ideas and approaches that you can use, increasing your own skills.

Review successes and failures, identify causes, strengths, weaknesses, so that you and your staff can build on success, and learn from mistakes.

Remove barriers that prevent staff achieving their objectives, because those are your objectives too. Get the extra resources, use your own power and authority to deal with obstructions or lack of cooperation from others in your organisation.

Accept accountability for what others do, as well as what you do. Accountability cannot be delegated: you will be held accountable for what is your responsibility irrespective of whether you personally do the work or it is done by others. Each level below you retains their own accountability, even if the work is delegated further down. For example, the director of a local authority social services department is accountable for how their section managers perform, and for the work of every field social worker. A Chief Constable is accountable for what every PC does.

Praise and reward more than blame. If staff are successful, thank them , and let them know you are aware of and appreciate their success. If things go wrong, find out why, and how to help them.

Develop training plans for each person, based on their existing attainments, knowledge and skills, and what they will need in the future. Ensure they can do what is expected effectively and efficiently.

Have career plans for your staff, based on what they can do, what they will be able to do, and where they want to go, and help them work towards their future.

There is a rule that every manager should understand and communicate: successes are due to the people who did the work. Failures are the fault of you the manager.

It is your responsibility to ensure your staff can deliver: you must enable them to do so.

Thursday, 11 December 2008

Delegating for results

It is always good to get positive feedback from people (and important to give it, too), so I was really pleased when someone said that some advice I had given her was the most effective she had ever received. The advice was on how to delegate. She was a specialist who had taken on an important management job, involving several workstreams, frequent unexpected and complicated additional tasks, and a team of people of varying experience.

When I first met her she felt she was having too many problems, had too much work to do, and not getting enough from her team. A few questions showed that she was doing work that others could do for her, that she was not expecting enough from her people, and that she was spending too much time reacting rather than controlling.

She wanted to delegate, but had found that it took longer to explain than to do it herself, and she had to spend too much time ensuring tasks were done and then allocating and defining the next.

I suggested that the key to her problem was that she was delegating details. one after the other. By concentrating on specifics of how to do something step by step, rather than allocating a specific outcome and leaving the person to work out the steps for themselves, she was taking far too much of her time, and the other person's.

The secret to effective delegation is to accept that someone else may not do something the way you do, and may take a bit longer the first time, but that is still better that you doing it, or micromanaging the other person to ensure they do it your way. The way it is done is usually far less important than getting it done. But delegating outcomes still has to be done properly to work.

Here are my views on the key factors:

Delegate outcome, not tasks: ask someone to organise a meeting of sales managers, off site, one day, rather than a succession of tasks allocated one after the other, such as find a venue for a meeting of 30 people near the office for a day, and then check diaries, and then contact all the sales managers, and then set up speakers etc etc. You don't want the tasks done for themselves, you want a sales conference set up.

For this to work, you should provide a clear, succinct brief. Unless you are setting up a relatively big project, one page is usually enough. Writing it down is not essential, but helps to clarify your own understanding of what you want, as well as being helpful to the person you are delegating to. It should state the desired outcome, the important factors that apply, the timescale and the budget available, for example, an expanded version of this:

  • Arrange Sales Managers Meeting in May, on a Friday, all day, off site

  • Conference room with projectors, white boards and usual high level stuff. 30 attendees.

  • Subject: new sales and marketing campaign – coordinate with marketing department and sales director

  • Budget for event £50k. Use secretarial support from team.

  • Give me weekly report: one page: Achieved this week, planned for next week, problems and issues.

  • Seek advice where helpful. Inform me of issues that need my help. Complete arrangements within six weeks.

This approach should ensure that both parties understand what they are trying to achieve, and the general terms of reference.

As a manager you should bear in mind two overriding points. Firstly you may make someone else accountable for something, but you can not delegate your own accountability: you are still accountable for the outcome even if you did not do the work. Secondly, you are responsible for ensuring the person can do the work: it is your job to remove barriers, enable them by giving them the right resources and authority, and encourage them to develop new skills. One idea is to include in the brief the fact that the person should also produce a checklist and short guide for the next time something like that has to be done, whether they do it or someone else does.

Future pieces on this blog will explore some of the issues here in more detail.

Tuesday, 9 December 2008

Indispensable? Fire them now

If you have a staff member who you think is indispensable, the best thing you can do is fire them right away. If they think they are indispensable, fire them even faster. If you think you are indispensable, stop it now. There are a number of reasons for this.

The first, and most important, is that by firing them you will almost invariably find that they were not, after all, actually indispensable. They made themselves appear so, but in reality they can be quickly replaced, or other people can do what they did at least adequately: in fact, often the indispensability is due to what their own staff do, not them.

Secondly, people who think they are essential will sooner or later hold you to ransom. They will demand pay increases and/or other benefits with the implied or actual threat that they will leave. And usually, they will do this when they think their loss would cause the most damage. Fire them now, and get it over with. That way you are in control.

Thirdly, anyone who is a manager or supervisor with the power to make decisions who does not ensure they have not just succession planning in place, but that there are others who can replace their work is a failure. They themselves can never be promoted, because they are indispensable in their present role.

Fourthly, a key responsibility of a manager is to support, mentor, encourage, train and enable their staff to realise their maximum potential, and make the maximum contribution to the organisation. A manager not doing that effectively is not doing the job they should be doing.

Fifthly, if someone really is absolutely Indispensable, you need to know that for sure, because you may lose them for some other reason, such as illness or accident, or a competitor, at any time. Might as well fire them as soon as you can put in place arrangements that render them dispensable, and before they hold you to ransom or drop you into something nasty by walking out at a bad time.

And if you think you are indispensable, consider that your manager will be considering these things about you.

Friday, 21 November 2008

Process following getting in the way of outcomes

We now have, in many organisations, a culture where processes take priority over purpose. When the concept of Business Process Re-engineering first began to spread, the promoters and practitioners were clear that it was a technique to revise and re-design work more efficiently, to eliminate unnecessary activities, and ensure the correct steps were taken and nothing overlooked. This involved mapping processes step by step around work flows which took a process, for example creating an invoice, from sale to printing to recording, through the minimum steps, but all the steps, needed to carry out some action. Bearing in mind how work and tasks grow and grow over time, some spectacular improvements were implemented.

Now, there are too many organisations, especially in the public sector, where their natural affinity for bureacracy, form filling, and back covering has interbred with poorly understood management jargon and corner cutting lowest price bid acceptance, to produce a tick box culture. The tragedy of the Baby P death demonstrates many aspects of this.

The management defended themselves by saying that 'correct procedures' were followed, that no mistakes were made, and they have three stars for efficiency. Yet the baby died. Every worker ticked each box at the right time. Every step was completed and form filled. Yet the baby died. The processes, workflows, forms, computer systems, scorecards, traffic light performance management, deadlines and so were followed impeccably. Yet the baby died.

The object of all the processes and procedures was to protect the baby, and that was the one thing that they conspicuously failed to do. The same problem occurs throughout business and government: no one makes any mistakes, but the whole point is forgotten.

There can be no clearer indication of how wrong things have really gone when it becomes apparent that the computer system designed to help staff work more effectively in fact takes up more than half their time.  This is an extremely common outcome for large computer systems across the board, and a future blog will try to explain why this is. The essence though is that the systems are designed by people who do not understand how and why the people who will use the system really work. 

The only practical solution is to revisit these processes and procedures, simplify the checking and form filling, and refocus on the outcomes not how to get to them. A simple tool for doing this is to evaluate each step as to how important it is on a common scale, what are the real risks surrounding it, and what does it contribute to the outcome.

Drugs, risks and bad counting

Last week saw a lot of articles, like this, on the 'wonder drug' rosuvastatin (Crestor), which apparently cuts heart disease risk by 40-50%. 

To emphasise the benefits, the drug companies like to talk about relative risk reduction, rather than the more helpful absolute risk. To illustrate the difference, anyone can improve their chances of winning the lottery by 100%. All they have to do is buy a second ticket. The absolute chance of winning is still rather too high to change your way of life in anticipation of a win - about 1 in 7million.  So to understand real risk to an individual, the figures need to be examined. Ben Goldacre in his Bad Medicine column in the Guardian talks about this.

The details of the research project (Jupiter) show in fact that for the 18000 people in the study, the absolute difference in death rates for ALL causes between those taking the drug and those on a placebo was 49 people (247 to 198). Only 400 heart disease events, such as heart attacks and strokes occurred in total for both groups, about 2.2%., but over half were medical interventions to deal with symptoms rather than sudden illnesses. Only 12 people in each group died from strokes. At the same time, about 100 extra people on the drug developed diabetes. About a quarter of the people dropped out, before the study was stopped after less than two years because of its startling 'success'. If the study had continued for five years there would have been no one left at the end. Coincidentally, although it is not often mentioned, about 25% of people on statins have side effects such as mental impairment, muscle pain, memory loss etc. Other studies (GISSI-HF  and CORONA. for example) have shown that rosuvastatin provides no benefits.

So why are AstraZeneca funding such studies and trumpeting trivial outcomes as huge percentages in relative risk reduction? Could it be that they would like as many people as possible taking an expensive drug every day for 25 years? The current preferred drug, Simvastatin, is now off patent, and therefore cheap. As an illustration, one US commentator pointed out that to save one life using Crestor would cost almost half a million dollars (400 person years of the drug to avoid one death). So, rosuvastatin is a me too drug designed to reinstate an expired patent, rather than produce any other result. 

This is clearly not getting it right. The purpose surely should be to look for cost effective ways of reducing ill health, not selling drug products. Of course, these research studies are expensive to run, and all of them rely on funding from drug companies. None of Big Pharma can or will spend money on comparing their drugs with other solutions. Thus we have extensive testing trying to prove for example that statins reduce coronary heart disease compared with a placebo, but none comparing the drug with normal health improvement measures such as reducing weight, changing diet, exercise. 

There is one interesting fact that has yet to be explained about heart disease. The incidence started to increase noticeably in the 1920s, and peaked at the beginning of the 1970s, since when it has decreased dramatically, by about two thirds in real numbers (from 714 deaths to 194 per 100,000 men aged 55-64 between 1968 and 2005, for example).  Perhaps the right thing to research is what brought about these changes, and how we might extend it.