John Mendzela explains why change projects often fail to meet expectations, and outlines how to achieve rapid and successful results.
Projects - Control v Passion
(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:
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:
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:
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:
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.
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:
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:
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.