Book How to Save a Failing Project

Preventing Project Failure

Business projects fail for many reasons, most commonly unreachable objectives, bad cost estimates and weak quality control. Excessive optimism is an especially widespread pitfall in planning. A “collusion of optimists” will end up with unrealistically lofty project goals.

“A successful project can be defined as one that is completed within a set budget and schedule and that meets identified goals and objectives.”

Poor project management is a pervasive problem that cuts across many industries. Surveys of software development projects show that about 75% either took longer than planned or failed outright. But, typically, project mistakes are fixable. Leaders and team members can put most wayward projects back on a productive path. Many projects fail or encounter delays because of oversimplified planning. Just scheduling, budgeting and monitoring a project is insufficient for producing satisfactory results. Project managers first must identify all the products the project team must create. That is the output of their work assignments. Then managers must identify the resources the team needs to do that work. Best practices also include restraining the scope of a project, updating the plan as a project unfolds, changing processes to improve quality and efficiency, and measuring progress in ways that spot problems as they emerge, not after they become entrenched.

Trouble Signs

Some signs that a project is struggling include missed deadlines, defective processes and reworked products. Another signal of trouble is relying on a handful of project team “heroes” rather than on the contributions of the entire team. Shifting customer requirements also could portend a slowdown in the project if customers make changes frequently or their alterations multiply rapidly. The absence of a contingency plan and continual changes in team personnel are two additional indicators that a project has uncertain prospects.

“Completing projects often takes more than twice as long and costs twice as much as we estimate.”

Responding defensively to negative project updates is unproductive. Projects are likely to veer off course if the manager reacts to reports of problems with criticism instead of open discussion oriented toward finding solutions. Rather than continuing to advance with a flawed project, managers should suspend and redesign it. Few projects move ahead according to the original plan, so anticipate having to update any plan in response when unexpected developments occur. This kind of flexibility is critical to getting value from a project.

“Underestimating the effort needed is a major reason projects get into trouble.”

Some broken projects suffer from poor communication, particularly when the staff members involved don’t share a unified perspective. In one case, poor internal communications sidetracked a $250 million software-development project. The software company designated a main team and 15 subteams to complete the project. However, subteam leaders communicated only with the members of their squads and never with the main project team. The firm ultimately redesigned the project to improve communication and coordination among the subteams and the main team, putting the project back on track by promoting a “single vision of the finish line.”

Matching Resources to Tasks

Project planners should focus on the crucial components of planning, including a “product breakdown structure” (PBS) that defines each component of the project’s output – not just the end products for customers, but also progress reports, technical analyses and other types of workers’ efforts for internal use. A plan also requires a “work breakdown structure” (WBS) – a collection of estimates of the resources required for each piece of output. Use the WBS to create a “resource-loaded schedule,” showing each task’s due date plus a list of the details of how to deploy staff and other resources to complete each job on time.

“Managing the scope of a project causes project teams more difficulty than any other part of the project.”

Allocate about 10% of your total scheduled project time to early planning and to continuing “maintenance” discussions of project bottlenecks and amendments to the plan. The project plan should include a built-in “process model” that outlines the inputs and outputs for each discrete task. This means dividing a project into many small tasks – measurable in hours, not months, weeks or days. Performing some tasks twice or more often may be inevitable, so allocate a budget to cover a certain amount of rework. However, introducing excessive rework, especially late in a project, often puts it over budget or behind schedule.

“The most common reason projects fail is failure to evolve the real requirements.”

Plan to monitor “leading indicators” – not “lagging indicators” – of the problems festering inside a project. For example, an error in the resource-loaded schedule could be a leading indicator of a problem. Compare the actual time and resources staffers need to complete tasks to the original estimates. Uncovering inaccurate estimates early in a project and addressing them promptly mitigates the associated costs. Employee frustration, customer disapproval and other lagging indicators are too dated; they point to problems in a project after they have started and, in many cases, have worsened.

The Human Factor

Bad personnel decisions trump good project planning, so proper staffing is vital to a project’s success. Build a team with a balanced set of skills. Avoid building a lopsided team with a concentration of skills in one area. For instance, a team with too many engineers and too few managers may struggle to keep a job on schedule and under budget.

“Rework, especially late in the project life cycle, is a leading cause of missed deadlines and overspending.”

Project managers can nurture intrapersonal cohesiveness by holding weekly team meetings to discuss the project’s progress, assess team performance and amend the plan, if necessary. Discipline or dismiss team members who hurt morale by ignoring the process model. Cultivate a culture of openness among team members to help them pinpoint and resolve problems. The project will benefit if the manager insists that team members admit and address their errors rather than ignore or even deny them. The manager should lead by example when it comes to honest assessment and continuous process improvement.

Breaking Projects Down

Team members must create a tangible product as they finish each task in a project. For example, the product involved in a residential building project could be anything from construction blueprints or permit applications to schedule reports or a completed new house. A well-prepared plan should describe each piece of output in such measurable units as items, pages or slides.

“Using statistics-based decision-making techniques allows the project team to make decisions based on facts rather than feelings.”

Your project breakdown structure should identify all the products in your project, estimate the cost of each one, and define quality standards. Quality needs obviously vary among elements in the PBS. For example, blueprint errors have greater consequences than misspelled names in the team’s meeting minutes.

“If you don’t update the plan, it soon becomes obsolete, leaving your project without the direction it needs.”

Failing to plan for the work required will put a project behind schedule the day it begins. That is why the work breakdown structure must define all the endeavors necessary to create every piece of a project’s output. This tool helps project planners select team members with the necessary skills. For example, imagine that you must hire personnel with the right set of skills to develop a city park. The team would include people who could oversee the installation of playground equipment, park benches and shelters. Perhaps less obviously, you’d also need to hire staffers who can make sure the project complies with building codes and passes safety inspections.

“When processes aren’t documented and followed, project teams end up trying to reinvent the wheel.”

Tasks in your work breakdown structure fall into two categories, “managerial work” and “technical work.” Each type of effort produces external output that you deliver to the customer and internal output that stays within your company. Companies have “internal expectations” about project revenues, costs and profit margins, and customers have “external expectations” about the impact of the project’s output on their own operations. Completing most units of output will require various activities. For example, building contractors must get the approval of their customers and of regulators before finalizing construction blueprints.

“We seem to prefer to hear very bad news at the end of a project rather than in small doses earlier on, when problems actually crop up.”

Measure and track your project’s progress in such “inch stones” instead of milestones. Schedule multiple tasks that will take short time spans to complete, not a few tasks that will take weeks or longer. Managers can adjust a plan that is divided into many inch stones more effectively than one with just a few milestones. Detailed schedules incorporating inch stones also help project managers align the expectations of customers and factually justify commitments of time and money. Inch stones provide a clearer day-to-day picture of progress than milestones.

Documentation and Communication

One way to minimize the risk of project failure is to create “minischedules” for achieving individual inch stones. You can also document team processes and monitor performance to foster “repeatability, consistency and continuous improvement.” Process documentation can serve as a training tool when new members join the project team. Regular replanning and making the effort to keep a good team together also limit failure.

“No resource is better than the wrong resource.”

Ineffective communications can put projects at risk. Stakeholders should all have the same understanding and expectations about a project’s purpose and its scheduled completion date, even if their other expectations about the project may vary. Build in effective communication among your stakeholders to allow them to discuss their respective needs.

“A project’s culture may impede project success.”

Make regular meetings part of the project schedule, and budget in advance for the staff time they will consume. Meet regularly from the early stages of a project to assure productive communication among team members, their superiors and their customers. Review the minutes of the previous meeting to remind yourself of the points you need to cover. One project manager found that when she had to run a meeting, she benefited from writing the minutes beforehand – creating a draft for later additions – and using them to help participants stay focused on the itinerary. This step also helps the manager prepare for the meeting by thinking through the issues on the agenda.

“The best results are not produced by the heroic efforts of a few individuals acting alone, but when the entire team works together.”

No other challenge in project management is greater than containing the scope of the project. Frequently replanning a project can keep it vibrant but also will expose the project team to the potential of “scope creep.” Focus on your mission and try not to broaden it.

Reducing the Risk of Software Project Failure

Software development teams enhance their prospects for success by decreasing their project’s complexity, disposing of unneeded requirements and matching their level of effort to the individual priority of each one. Software development also goes more smoothly when the project team confirms that it can test the viability of each component. Avoid discovering late in a project that certain requirements defy testing.

“Build quality into work products, rather than trying to add quality to work products at the end of the project.”

Work closely with software development project customers to be sure you understand their “stated requirements.” These planning statements become the basis for determining the project’s “real requirements.” Failure to determine commercial software customers’ actual needs is “the most common reason projects fail.” Make sure you can trace all the elements listed as necessary back to the source – or customer – who wanted them.

Build attention to quality into all project processes rather than attempting to insert quality in the late stages of a project. Conduct “defect prevention” by categorizing problems, prioritizing each category and focusing on finding solutions for the most important ones. Statistical analysis of project data is a common form of quality control that works best in combination with subjective, experience-based judgment.

Software developers urgently need to spot and eliminate defects as soon as they inject them into programming code. This conserves spending on the project. Defects that remain intact throughout multiple phases of a software project are more costly than those you eliminate early.