Showing posts with label management. Show all posts
Showing posts with label management. Show all posts

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.

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.

Friday, 21 November 2008

Things going wrong

The government has spent untold billions on the National Health Service, but there seems to be little improvement in many areas. They have spent more billions on huge IT projects for the Inland Revenue, but they have not worked. The Child Support Agency was a disaster, railways are a mess, education has fallen to pieces. It seems almost all huge projects fail, almost all 'improvements' make things worse. And althought these are public sector examples, the private sector has just as many horror stories (see the banking system), but usually they are kept private.

The question then is why does all this effort to make things better do the opposite. The management guru Charles Handy describes the two error types: type 1 is getting it wrong, that is making mistakes and other types of failure,  type 2 are not getting it right. Almost all of these failed projects and changes are type 2 errors, where avoiding obvious mistakes has taken precedence over achieving the intended outcome, which has dropped from sight.

This blog is a personal view of some of these type 2 errors.