Project Rescue

© 2002 millennium strategies

Overview

While the whole world of projects is very large, research by the Standish Group into one corner of that world - internal application development - indicates that some 3/4 of development projects fail to meet their schedule and budget with the average project cost at nearly twice the projected cost. Disturbing numbers to say the least.

In our experience with facility construction and technology systems implementation the numbers are not nearly as bad but there is often room for concern. While most projects do go over their budget or schedule, it is by margins of less than 20%. Even so, there are many issues that need to be understood and resolved to assure that a project has an even chance of being accomplished within the intended timeframe and budget.

Causes

The causes for errant projects as we understand them are diverse to say the least. The most prominent among them, not necessarily in a particular order:

• • Incomplete requirements definition  Ambiguous or incomplete requirements in planning will assure scope creep, redundancies or rework during the implementation.
• • Wrong level of user input  When users or direct beneficiaries are not fully involved in requirements definition or little attention is paid to their ultimate acceptance of the project deliverables there will be probably be resistance to the solution. On the other hand, when users are too close to the requirements definition, the work plan may be based on inaccurate assumptions and organizational misunderstandings that may build serious conflicts into the work.
• • Unrealistic demands  Powerful or influential stakeholders may pressure project team members into assuring that they will meet unrealistic demands. In addition, a lack of acknowledgement by the team that problems are imminent and overconfidence in the capabilities of the team by project leaders is a formula for disaster.
• • Lack of executive support  The wrong people making important decisions or lack of real or appropriate stakeholder involvement compounded with intentions of compromise among competing stakeholders at the beginning that turn into conflicts of interest or priorities when things get under way are examples of defective executive support for the work.
• • Inadequate change process  The lack of foresight to account for changes in requirements or the project environment combined with inflexible project procedures possibly exacerbated by a lack of a change definition and management processes will rapidly destroy project progress.
• • Defective planning  Defects in the original schedule, resource estimates, deliverables requirements or cost estimates that can only be overcome by assumptions that suspend the laws of physics or human endurance will doom the project. Just plain dishonest planning or pricing to achieve a short term objective or downsizing that cuts vital resources will have the same result.
• • Absence of need  Projects that are engaged with a lack of overall understanding of business process, functional requirements, technical standards, future needs or potential for growth and expansion will fail to meet any realistic requirements. Projects that are not needed and validated with a business case or offer no real advance over existing systems with no clear benefit to users cannot establish adequate metrics for success.
• • Incorrect team composition  The wrong mix of personalities or persons with the wrong skillsets assigned to the project team, including the wrong mix of doers and thinkers, that may include a lack of leadership will limit or prevent the teamwork needed for efficient delivery.
• • Lack of technical knowledge  Lack of familiarity with new technology or potential solutions, the lack of expertise in critical areas or an ineffective plan for integration of new technology with existing systems will probably result in serious gaps in the solutions. Combined with a lack of user training or ineffective technical or user support will prevent any gains from the project.
• • Poor execution  Ineffectual communication, progress tracking, coordination or decision making are examples of poor execution. Misunderstanding the difference between activity and progress with expectations that early achievement of schedule and budget will continue are also critical defects. Finally, failure is assured when once the problem is identified and nothing is done until the situation goes critical.
• • Incapable delivery  It is critical that the vendor or staff selected to do the work have the necessary skills, tools and resources, keeping in mind that there is more to vendor selection than low price. In selecting a vendor, significantly lower price usually indicates mistakes or lack of understand of requirements rather than unique capabilities. Vendor or delivery errors may be caused by having insufficient information to know what to do.
• • Wrong delivery methodology  Using a "ta-dah" delivery strategy where there is only one deliverable at the end of the project limits the chance to assure that implementation is according to expectations. Poor communication between the delivery team and project stakeholders to ascertain progress or discuss issues also increases the risk of failure. Finally, having multiple points of contact between the team and stakeholders often creates confusion and conflicting decisions.

Solutions

Very simply, the best way to avoid these problems is to prevent them from happening. Planning by prevention, however, is not a good way to get things done and planning, in general, has to remain the topic of another article. Here we want to talk about how we can help you get an errant project back on track.

A good place to start is to define a project: "an endeavor with a known start and end with the achievement of specific objectives to be accomplished within certain constraints." The elements of a project include:

• • Scope  what is to be accomplished as an assemblage of tasks
• • Resources  the skills, talents, tools and working environment available to do the work
• • Schedule  timeframe, sequence and dependencies between tasks
• • Quality  how closely the work aligns with expectations or standards.

Fixing a problem project requires changing one or more of the four project elements. Some of the ways that one can manipulate these factors to regain control of a project are outlined below.

One of the most tempting actions that is often taken first is to reduce the quality of a project by requiring less documentation or testing or using lower quality materials. This tactic may work in the short term, but over time it will significantly increase the total cost of ownership. The project may seem successful, but one is building in significant, and oftentimes, unknown problems that will only appear in the future.

It is nearly always necessary to carefully balance all of the options that are available and work to develop additional options that may not be obvious. This nearly always requires someone from outside the team who is able to clearly see the whole issue without being mired in the conflict. Unless the project team is able to learn from mistakes and build more robust processes for the future, it may be most prudent to simply develop a new plan and direct the implementation rigorously.

An effective approach is to separate the past from the future. What has been spent is sunk cost, what has been accomplished may or may not apply to the final product. To do this requires an objective and reliable assessment of what has been accomplished and what it will take to deliver the defined project requirements given the present situation. It is then necessary to assess whether the benefits from project completion actually warrants further expenditure. Your options are then to either accept what you have with limited capability, abandon the work or clear out what is not suited and build on what is left using new methodologies, new resources or new requirements definitions.

To be successful in this it is necessary to diagnose the root cause of problems and quickly determine exactly what needs to be done to repair or mitigate the problems. It is also necessary to know the options available to overcome collateral damage and what level of knowledge transfer is needed to help avoid problems in the future.

Avoiding problems

Some of the ways to avoid problem projects include:

• • Define requirements with modest detail; include everything that is needed but no more
• • Manage scope creep through careful tracking of progress and clear reporting
• • Clarify requirements and know what is important to support business functions based on technical capabilities
• • Focus on requirements and deliverables in the planning process
• • Build a solution to meet business objective, not a monument to technology
• • Choose a vendor with financial capability that can finish the work even under stress if needed
• • Provide as much information as possible; reduce everything to writing and keep track of all communication
• • Cover all bases equally: business, technical and functional; hire experts to help out
• • Know where the risk factors lie and be clear up front who is responsible for managing each one
• • Know what constitutes a completed project and each deliverable or subproject; define tests and metrics for successful completion
• • Have the right vendor on the job; match their skills to your requirements
• • Use single prime contracts to avoid conflicts and push coordination as close to the work as possible
• • Break large projects into small steps with concise deliverable cycles
• • Use pilots and prototypes to incrementally develop the solution
• • Maintain careful oversight, maybe an outside observer who can be more objective and identify problems sooner
• • Hire the most experienced and skilled people that you can; contract for short-term engagements
• • Change from waterfall planning to rapid application development methodologies