About the Author

Why?

Back to Basics - Back to the Future

Project Type

Stakeholders

Leadership and Team development

Focus, Planning and co-ordination

Learning and review

The Perfect Projects Master-class

New Learning in a New Way- Pentacle The Virtual Business School

e-Clubs/VoiceWorks: When you’re on you’re own you’re not alone

Ordering stuff: Project Pointers, Books, Posters,

Why?
______________________________

If you’ve read All Change! you’ll have met Franck my alter ego. You’ll also know how to successfully deliver projects in the New World. This book fills in some of the sharp right-angled corners that All Change! smoothed off.

If you haven’t read All Change! read it soon. It will multiply and enhance the value of this book to you.

These short essays on project success were told to me by Franck on a number of evenings throughout last year. I’ve repeated them to some of the readers of Project Management Today. And now I’m going to tell them to you.

They link back to my Formula for Project success

or in English

Back to Basics - Back to the Future

_________________________________

Change is the cause and the effect of itself.

The last decade has taken us on a whirlwind journey. Social and technological change have provided opportunities for enterprise which have led to the explosion of communication, travel, trade and infrastructure changes such as the internet. Each opportunity exploited simply creates another. For example, the availability of a graphical user interface allowed the development of browsers, which in turn allowed the development of websites requiring better browsers with faster access than a modem, to digital connections and so on, almost exponentially. And even when the market slows, the change accelerates and your workload and pressures go up! Large drops in share prices lead to opportunities for deals, acquisition and merger, and synergies requiring retraining, re-organisation and so on, almost exponentially.

Unfortunately organisations including yours are caught up in this buffeting. Buffeted by tides and changes greater than themselves. Most organisations are creatures of habit, preferring the industry sectors they understand to the business- sphere they don’t. Preferring internally driven programs to those inspired from outside the organisation, say by customers. For many organisations their concession to their customers in a wired world is a website, developed by an out-source supplier which is simply an animated version of a corporate brochure or annual report. This leaves a real opportunity and advantage for any competitor who takes the time to carry out real change, big change, effectively and successfully.

Now change feeds on change to the point where for most organisations, the pace of change in their business-sphere has outstripped their ability to learn and change. This is the New World.

Programmes and projects have taken over from processes and procedures

In the New World the opportunities for change are almost endless. In the 1990’s the focus of most enterprises was on change but simultaneous change - the type found in operations, processes and procedures. Improving, redesigning and re-engineering them ran a close second to realigning functional reporting lines as a way of getting better, of getting change to happen.

After a long but unsuccessful innings Enterprises began to realise that to alter anything at all in the organisation, from its structure to its supply chain, to its market access, required that they learnt how to tame change, how to deliver BIG change, how to deliver sequential, discontinuous change. They discovered the need to deliver very big change by breaking it into smaller chunks. They have begun to understand that in the New World with significant change, it becomes effective to ensure that the projects (chunks of change) are aligned closely into programmes (big flocks of chunks which like birds, fly in the same direction close to each other) in order to have effective implementation. They have discovered the essential need in the New World to manage projects and programmes of change.

This is the decade of the Project and Programme manager.

If you understand what type of change you’re dealing with the issues are about 95% predictable

Now we have begun to understand that projects go wrong following common patterns. My now famous and widely published bubble diagram summarises the typical ways in which projects go wrong and why.

We have begun to understand how to interface a project or programme and its organisation with the rest of the enterprise. Now we have begun to understand what tools to use, and when, the importance of stakeholders, the critical difference between open and closed change. We have begun to understand how in the New World projects exist against a backdrop of uncertainty. This means that often we cannot completely pre-plan everything but have to evolve the plan during the project, whilst at the same time, risk and loss of focus become real threats to making projects range in type from ‘Foggy’ (something must be done but what and how?) through Quests (the goal is known but not the method) and Movies (the technology or method is decided but the deliverable have to be negotiated) to the traditional and closed ‘Painting-by-numbers’ projects (goals and methods known).

We have begun to understand why a significant proportion of joint ventures end acrimoniously. In several countries the legal system is being revised to encourage completion of projects, which in turn deliver benefits rather than continued legal wrangles, which result in non completion.

As New World project and programme change management becomes more precise, the focus needs to shift from the delivery of the project to ensuring that a real benefit is achieved.

Global Change

Leading across cultures and virtual teams requires a full ‘utility belt’ of tools and the ability to create an overriding supportive environment

In the next decade our ambitiousness on both project and programme delivery will continue to increase. As ‘global’ becomes a standard scale even for medium sized organisations, programmes and projects will routinely have to cope with rapidly building teams made up of multiple national cultures. A good ability to lead and develop virtual team working will be essential. And the ability to create 3*8hr teams (where the implementation team passes the baton from one team to the other around the globe on 8hr shifts) and many other new forms of work will be required.

Of these, the most challenging will probably be that of quickly creating a common project/programme culture across different national cultures.

Web-enabled Change

The web is the tortoise upon whose back we create our new world of programmes and projects

The ever-pervasive web of the internet will provide the unique infrastructure for supporting projects. It will provide training and development for you, project leaders and programme managers. It will provide the tools that you will use for knowledge management, reporting and communication. It will provide the link between you and the stakeholder benefits the programme or project is to achieve.

It will provide just-in-time advice lines and expert guidance and opportunities for collaboration. (For example visit http://allchange.com or phone +44 (0) 121 111 3286)

Change as the Organisational Structure

If change is the norm, the organisation structure and environment ought to reflect it

In the coming decade projects and programmes will further eat into the Old World hierarchical command, and control functional structure of organisations as the relative amount of repetitive, operations-process based activity declines in favour of the up-gradable, one off project/programme activity. It will make less and less sense to think of a career in linear hierarchical terms. To think of a function such as marketing being anything other than just a long string of programmes, will seem old fashioned.

Delivering Change in a New World

Speed, perspective and discipline beat everything else

The New World, encourages the faster, more-effective delivery of successful projects at an increasing pace. The key factors of speed, perspective and discipline become essential to the success of programmes and projects. However, to achieve speed it is essential to understand the place and role of stakeholders in order to achieve emotional engagement, and as a result to reduce resistance to change. To achieve perspective, it is important for the project to always be viewed from the big picture of the enterprise as well as the immediate objectives. The development of project leaders, the development and fulfilment of team members’ aspirations, and the guidance and support of the programme managers all contribute to the disciplined delivery of benefit.

Harvesting the benefits of change

Change and improvement are not the same thing. With improvement there is benefit. It’s because of the benefit that we bother to change

I also believe that our ability to understand and implement big change using projects and programmes, will make us more selective of the challenges we take on. The focus on benefits will mean the death of functional and departmental projects. All projects will be business projects. Enabling and infrastructure projects will transform themselves to be intricately linked with the benefits that they underpin. They will no longer stand alone.

Skills for creating a New World

When I grow up I want to be ... a project leader?

A statement never or rarely heard from a 5 year old, and yet the New World makes the roles of a Project Leader and Programme manager more exciting and challenging than they have ever been.

The future is bright based on what we have learnt in the past, the basics of project success. To your advantage, Project leadership and Programme management will continue to be the most transferable and sought after management skills.

Project Type

___________________________

Why IT projects are Doomed!

What do Boo.com, the National Fingerprinting Project, Taurus and the millennium dome have in common? Easy question - easy answer: vast overspends without the hoped for results. But only the first three involve significant spending on IT without any real tangible result. Although you may not realise it, the odds are sacked against you if you start an information technology based project. There are a number of very sound reasons for this.

The risks and chances of success are predetermined by certain characteristics

Imagine this scenario. You are buying a car. You say to the salesman, "Well, I may need to get around." <Definition statement>. The salesman offers to study the problem and returns two weeks later with a ‘driver specification’ which contains sentences such as ‘... a circular interface will be used to orient the appliance and the driver will be responsible for ensuring that they are fully trained in the administering of the energy source...’ <User Specification>. You are asked to put your signature to this document. How do you feel? If you don’t sign it off, nothing else will happen. If you do sign it off you condemn yourself to months or years of not being able to confess that you didn’t really understand, and hadn’t really thought through the document you signed <Signoff Process>. The salesman then disappears and reappears two weeks later to inform you that his team have now worked out what they need to do. You decide to take a look at this other document, only to find the contents completely bewildering - statements like ‘a minimum initial accelerator pedal compression to national speed limit not to exceed 20 seconds...’ and so on <Systems/technical specification>. To you, complete gibberish. You give up and try to hide from the salesman in order to avoid the embarrassment of being asked questions you don’t even understand. The salesman persists. Every month you are brought another item to test. First the back of the seat, then the windscreen and the hubcaps <prototyping>. They all look well made, but eventually when you are presented with a green and pink Reliant Robin you realise that something must have gone wrong somewhere. You are amazed by the defensiveness which accompanies your criticisms. You are told it’s your own fault - after all you signed off each stage!

An exaggerated example to make a point, but it is actually worse in reality.

Projects are ‘chunks’ of change we carry out to remedy, or take advantage of other changes around us. However, these chunks are not all the same. Depending on the level of learning and experience we already possess when we begin, the chunk can be "closed". There is no need for learning and no discussion. We understand why we are doing what we are doing, what precisely the outcome will be, and understand how it is to be carried out - including the methods and technologies required. In today’s fast paced new economy, my estimate is that this type of change accounts for between 10 and 30% of the change that most organisations face. Far more awkward is a climate of change with a missing method but clear goal - or a chunk of change with a clear goal or methodology but a lack of clarity on outcome - or required change which lacks both direction and method, but simply exists because ‘something must be done’ to get away from a real or perceived threat, or to take advantage of a real or perceived opportunity. I call these different change types, in order, Painting by numbers, Quests, Movies and Fogs.

However, there are two other criteria which influence the chances of success. The first focuses on how easy or difficult it is to measure and monitor progress. Physical change - like construction, is highly visible whilst changes to culture or, for example, to the corporate brand image are highly invisible. You can guess which one is going to be harder to deliver on and why. Invisible change lacks clear signals of success to those involved, and the predictability and quality of the end product is hard to determine before it is too late.

Openness, visibility and the human reactions to change are critical to your chances of success

The final arbiter of risk and success depends on whether the party carrying out the change, is the same as the party who has to live with the results. As you may have guessed, having the parties in different camps (external change) forces clarity on contracts and agreements. Having them in the same organisation (internal change) doesn’t. In fact, the only situation which is more complex than internal change is Joint Venturing, where the potential for adversarial conflict associated with the external project is amplified by the internal political issues.

So why are IT projects doomed? Simply because they tend to fall into the more awkward and risky types; for example, the quest ("We must be able to have immediate access to all our enterprise information" or "We must have client information immediately at the touch of a button". Great, but how will we get there?) or the movie ("We’ve set up our webserver and employed 30 Java programmers to e-enable our business". Great, but what will that look like?). What’s even worse is that for most of the life of a technology project it remains completely invisible. And finally, a significant amount of this change is internal or abdicated externally.

Let me summarise this for you without the jargon. You have a project in which some of the actual project work is going to be defining the goal, or proving the technology or method where progress is not obvious or measurable, and can get bogged down either in internal politics or indifference or in contractual wrangling. Now do you see why such projects are doomed?

Secondly, IT projects are doomed because the key groups of stakeholders are either unrealistic optimists or unclear ‘ignoramuses’. The stakeholders who have to live with the outcomes, referred to as ‘users’ or ‘the business’ fall into the second category, whilst the leaders and team members fall into the first.

New technology attracts optimists and marginalises Luddites.

Technology development in a fast changing world is bound to be difficult. It is also likely to attract people who believe in opportunities - who believe that things can work out. This is the problem. A standard role team profiling or leadership profiling questionnaire of project leaders and team members identifies Doers, Solvers, Checkers and so on. But in addition, it should look for Optimists, and Dreamers. To undertake something as demanding as a major IT project requires a healthy dose of optimism, but this same optimism can undermine success. Recently I met with a client who told me that when carrying out acceptance testing one box at a time, with each box taking about the same length of time to test, his team members wouldn’t be even mildly concerned if after half the day, they had only made it a third of the way through the day’s test goals. If asked what they thought and what they intended to do, they would reply merrily that the testing would be complete by the end of the day.

Remember, optimists always assume the best rather than communicating concerns and checking small issues.

Let me summarise the second point for you. One group expects benefits they can’t fully describe, whilst the other, the group of optimists, believe "it will come out right" long after the early warning signals have been trumpeted. Neither group looks hard at how this will fit in with existing practice.

The third factor is the speed of change in the New World. We all know Moore’s Law that computer power doubles every 18 months. Less well known is the fact that information velocity - the speed of information flow is increasing by a factor of 10 every 3 years. At such a tremendous pace it is likely that any project benefits conceived will have a very short shelf-life indeed. In a piece of work I carried out with one client in the utilities industry, we discovered that any IT project which was not expected to deliver results within the first 18 months never paid back at all! The problem is, that projects are chunks of change we carry out to take advantage of new opportunities to fix issues in our existing enterprises. There are two components: effort and benefits. In most project schedules the project is defined as the effort - the work to be done to establish the change. The benefits are not defined as part of the project. It is assumed that somehow they will take care of themselves. The people who have to change their work habits, develop their skills etc. will just get on with it and all will be well. As a result, the people who actually have to change what they do on a day to day basis are rarely seen as the key stakeholders in the project. In addition, projects often ignore the dismantling of the pre-existing systems and infrastructure, which is often essential to encourage the changes required to reap the benefits.

Also, projects often fail to be effectively chunked. If broken down at all the breakdown is by effort not by benefit. It is more common to complete the development of a complete platform before adding applications, than to specify the platform and construct enough for the deployment of an early application.

In summary - The purpose of the project and the technologies contained in it, will get out of date so fast’ that it is easy to deliver a project which does nothing but present the enterprise with a huge bill with little obvious means of recouping the costs. Organisations who recently implemented enterprise wide accounting and reporting systems, which are now being upgraded to be web browsable, will recognise this effect.

What to do about it?

Even the more apparently risky open projects can be successfully delivered if the right method is applied. For example, instead of applying a ‘Method One’ style painting-by-numbers approach (see below) to a more open quest........

........ for a quest a parallel track approach (similar to RAD) should instead be applied.

Deadlines should be close and immovable.

In addition, anything and everything which can be used to raise the visibility of the project should be done. Mockups, prototypes, review presentations, stakeholder simulations, should be applied liberally as an integral part of the project.

There is a single best approach for managing each type of project.

The stakeholder management is also critical - the user stakeholders must be encouraged to fully understand what is going to change, and what is going to stay the same, as a result of the project. Again, simulations - ‘a day in the future of...’ - type exercises and communication using the user’s journey rather than the developer’s specification’ are critical. The other stakeholders, the team and leaders need constant reviews and checkpoints and a healthy dose of self criticism and cynicism, to ensure that risks and early warning signs are not ignored.

The Complete Project looks beyond the effort or the benefits and takes all into account in its planning and implementation

It is important to plan on the basis of ‘the complete business project’, that is, all the people and activities which have to be co-ordinated through change to give the overall business benefit. Projects should be phased not by technical requirements but instead by the efforts/rewards - that is, the flow of money to be ‘w’ shaped rather than ‘V’ shaped or in the case of complete failures, ‘L’ shaped.