Making Change Projects Succeed

(This article was first published in the Chartered Accountants Journal of New Zealand and is under copyright. If you use or quote from this material please attribute it to the author and publisher.)

Managers have always juggled time and resources to achieve objectives, maximise outputs and minimise inputs. But intuition and experience aren't always enough to get it right, and scheduling can become a complicated nightmare. This is particularly true for one-off, cross-functional activities: "projects".

It's not surprising that project management has expanded from specialised industries to become a best practice management tool. Today, sophisticated computer tools are cheaply available too. Yet project outcomes still vary from outstanding to disappointing. Why? Can we do better?

Perhaps we can, with some new thinking. Some projects fail through too little project management. But others fail through too much project management, of the wrong kind.

Origins and History
Project management began with "building" - large-scale manufacturing and construction. The objective was usually known - a finished result of a specified quality. Avoiding time and cost overruns was however not easy, particularly in complicated projects. Key resources were often in demand for other projects or cost money even when idle, so accurate scheduling was vital. Project management - formal planning and control of time, cost and quality - evolved to meet these needs.

When computers arrived, they were big and expensive too. Their design and production were large projects in themselves. The techniques of project management were soon transferred from hardware to software. Large-scale software development projects became commonplace.

But limitations to traditional project management began to emerge. Too many software projects (25% by some estimates) never reached completion at all, and many others produced a result that was no longer relevant by the time it was ready. Similar results emerged in manufacturing too - development times failed to meet market needs, or technically successful projects were uneconomic in the real world. What was going wrong?

Traditional project management developed in a relatively static world, dominated by technicians, supervisors and administrators. Control was the key requirement and centralised planning was the dominant management paradigm.

Today the focus of most businesses has moved from product to customer. Convergent methodologies centred on control do not cope well with the ambiguities and rapidly changing circumstances of the real world. The limitations of project management methodologies become most apparent in "people" projects such as restructuring - measurable objectives can be ticked off but destruction of intangible value is hidden. More project management of the conventional sort - tighter specification, "change control" procedures and added levels of oversight - isn't the answer.

Two Kinds of Projects
Traditional project management is most useful where:

• there are no complex linkages with other change projects
• the required outcome can be objectively and measurably specified
• the outcome and the environment are stable during the project
• linkages with other projects are few and simple
• resources can be simply specified and applied
• the timeframe is reasonable in relation to the task

The skills required to manage such projects are specialist knowledge, method, analysis, discipline and control. It is relatively easy to establish project sponsorship and management, assign responsibility and apply accountability. Risks can be identified and controlled. Managing the project parameters of quality, time and cost becomes mainly a science. Skilled professionals are available, internally or externally.

But what if these conditions - as so often today - just don't apply? Then, project management - of another kind - becomes even more valuable. Where outcome, environment, linkages and resources are uncertain and time is pressing, different skills are required:

• dynamically shaping and re-shaping the required outcome demands a strategic overview and a generalist approach
• managing the interaction between an evolving project and a changing external reality demands intuition and political skill
• defining, obtaining and managing resources - particularly a varied team of people - demands high leadership and management skills
• working with uncertainty under time pressure demands a risk-taking, entrepreneurial and passionate style

Success in a rapid dynamic project requires art as well as science, passion as much as control. These talents are hard to find, particularly when traditional project management skills and disciplines are still needed too. A checklist of do's and don'ts can help.

Rapid Dynamic Projects: Do's
Assign project sponsorship thoughtfully. Many good line managers make poor project sponsors. The sponsor (who must be internal) should:

• be outcome-focused
• understand key issues across the project and beyond
• have the "clout" to support the project effectively
• be comfortable with a high degree of delegation.
• tolerate uncertainty and ambiguity
• enjoy change

Choose the project manager with equal care. Someone from "inside the existing box" is unlikely to make real change happen. Look for the qualities listed above. If an internal person is chosen, consider external support and mentoring.

Create a vision and culture for the project. Project team members are pioneers - much will be asked of them. To succeed, they must be full partners in the enterprise. Keep the team informed and involved. Invite their views and consider these thoughtfully. If goalposts move, know why and share this knowledge.

Focus project management on the fourth parameter - scope. Deliver the necessary result, not the planned one. Be prepared to re-think the project as circumstances change. Weigh the risks of changing scope against the risks of not doing so. Use deadlines as a driver for achievement, not a straightjacket; see the project budget as an investment, not a cost.

Keep the team small. Every additional person involved with the project adds a communication and management overhead. Use the project sponsor and manager to maintain liaison with other parts of the business. Make the project the top (ideally the only) priority for other team members.

Balance the team:

• use internal people (for local knowledge)
• include external people (for fresh eyes)
• ensure a range of technical areas is represented
• mix personality types
• blend experience and youth

Manage dynamically. Monitor changes in risk probabilities and impacts, not just absolute values. Have several management strategies for each risk. Scan the environment for new issues. When crises develop, stress finding a way forward over detailed planning.

Manage economically. Generally, 20% of the system will deliver 80% of the result. Avoid clumsy steering committees, lengthy routine reports and long meetings. Keep the project focused on achieving milestones, not on protecting its rear.

Evaluate the project once it's over, regardless of the outcome. What did we do right? What went wrong, and why? And - most important of all - what would we do differently "next time"?

Rapid Dynamic Projects: Don'ts
Don't compromise on the people. Projects where a mediocre result may not matter too much can be used as training grounds or as a place to "park" surplus staff. Mission-critical projects need people who can make it happen. Search widely and select carefully.

Don't focus unduly on technical excellence or knowledge. Sponsor and manager need a broad focus. Core team members should be creative generalists who can link their skills and experience to other disciplines and the wider world. Short-term technical needs can be met with part-time or outsourced resources.

Don't rely on methodology. Any methodology is mainly a checklist to help the experienced professional achieve completeness and order. Once off the edge of the map, compass and common sense must take over. Elaborate monitoring and reporting mechanisms are expensive and often provide false comfort when things are going wrong.

Don't expect software to manage the project for you. On a dynamic project, an elaborate project plan won't help very much. If the project manager is unfamiliar with the software, it may even be a handicap at critical periods.

Don't throw the old disciplines overboard. Managing the traditional project parameters of quality, time and cost - doing things right - is useful. But defer reporting and analysis when necessary. Doing the right things at the right time is what will make the project successful.

Conclusion
In today's environment, the new kind of project management often has more to offer than the old one. Businesses that apply it operate in recognisably different ways. To produce superior results that often look like luck or accident to outsiders, they:

• see time as a key competitive variable
• invest in trying things out, not writing plans
• plan backwards from an outcome, not forward from the status quo
• have a passionate, can-do, risk-taking culture
• expect their executives to demonstrate leadership, not management

As traditional organisational structures and management methods become less relevant, project management will continue to grow in importance. But matching the tools to the job is vital. Too often, the old kind of project management is applied when the new kind is needed. Bureaucratic, hierarchical organisations feel comfortable with control-oriented methodologies that focus on technical issues. The discovery that - despite the acres of reports produced - the project has lost its way often comes too late. Everyone can provide an explanation, but no-one has delivered a result.

The simple message for organisations undertaking rapid dynamic projects is:

• focus on outcomes
• choose the right people
• trust the team to achieve
• manage flexibly
• be prepared to repeatedly re-think

This may feel unfamiliar. And it is risky; projects can fail. But the awesome return that a successful project delivers - passion plus control - is worth the risk. The greatest risk of all is to fail to change.