5 Lessons to Learn from a Failing Project

Projects do fail – no matter how big or small the scale of a project, and a Project Manager cannot avoid the risk of a failing project.

In 2013, for instance, Avon Products Inc. halted its $125 million SAP system rollout. This “Promise” project was a new sales order management system commenced in 2009 in Canada and took 4 years to complete. The purpose of this new enterprise software system was to build and introduce a “real-time” ordering system via the web and mobile devices. There were multiple vendors involved in the project; SAP for its back-end system and IBM as its front end solution. The issues arose when there were conflicts in the User Interface (UI) between back-end and front-end solutions. As a result, the system was not working correctly; it was not accepting orders, saving orders, or reserving inventory. It also had quality flaws and poor usability. As a consequence more than 300 Avon independent sales representatives quit their jobs because their sales targets could not be achieved.

So, what went wrong? There are many theories to consider but which parties or technologies deserve the blame for the project\’s failure is still debatable.

According to the Standish Group survey research in 2012, only 39 percent of IT projects succeeded outright (see Figure 1). 18 percent failed, and the remaining 43 percent were challenged (late, over budget and/or with less than the required features and functions).

 Figure 1:  The success and failure of IT projects in 2012

 

The Standish Group CHAOS Report also listed statistics on project failure factors based on data in 2009 in Figure 2 below.

Project Impaired Factors	% of the Responses
1	Incomplete Requirements	13.1
2	Lack of User Involvement	12.4
3	Lack of Resources	10.6
4	Unrealistic Expectations	9.9
5	Lack of Executive Support	9.3
6	Changing Requirements & Specifications	8.7
7	Lack of Planning	8.1
8	Didn’t Need it Any Longer	7.5
9	Lack of IT Management	6.2
10	Technology Illiteracy	4.3
11	Others	9.9

Figure 2: Statistic on project failure factors

 

There are a number of other signs that a project is in trouble:

• Excessive overtime, which is an indicator of poor project planning
• Lack of ownership at each level of the organization
• Inadequate resources
• Low team morale
• Poor communication
• Exceeding the budget with no clear timeline for completion
• Huge delays in achieving project milestones
• Scope keeps changing with no clear direction

 

What should we learn from a failing project?

The Project Management Body of Knowledge (PMBOK) defines lessons learned as the learning gained from the process of performing the project. Formal lessons learned sessions are commonly held during project closure, or near the completion of the project. However, lessons learned should be discussed, identified and documented during the project\’s life cycle. According to the PMBOK, the purpose of documenting lessons learned is to share and use knowledge derived from experience to:

 

• Promote the recurrence of desirable outcomes
• Preclude the recurrence of undesirable outcomes

 

 

So, here are five lessons learned that we can take into considerations when managing our projects.

1. Set the right expectations

How many times do we find ourselves facing a conflict between business requirements and project requirements? A business manager always talks about money, whereas a project manager talks about meeting a timeline and deliverables, while a technical consultant talks less and drives the technology. So how does a team achieve a common understanding and common goal?

Requirement gathering is the first step to project delivery. The initial requirement usually comes from business people on the front line to a customer. They should understand customer expectations and their pain points, work through their pain points and propose a better workaround or solution. Business people should propose requirements which are not only profit-driven but also technology-driven and feasible. They should make early engagement with the project stakeholder i.e. the solution architect, business analyst, technical lead and project manager in order to finalize the requirements gathering.

As a Project Manager, the proposed requirement must define the scope, time, budget, resource and risk concisely. These requirements are then documented and shared among other stakeholder i.e. project sponsor, project owner, team members so that everyone has a common understanding and the right understanding and overview of the project. This will eventually develop their commitment towards the project.

 

2. Exploit the project schedule wisely

The project schedule is the foundation of every project. A good project schedule will contribute to a project’s success. It should be drafted based on high level milestones and expanded further with project details. There should be a checkpoint at every milestone to evaluate the health of the project.

There are several points to consider when drafting a project schedule:

• The schedule should integrate timelines from every team member who is contributing to the project deliverables
• Link schedule to resources’ availability
• Allocate a proper buffer especially when a task involves an iterative development method
• Use a proper scheduling tool to track project milestones
• Keep track of the project progress against the baseline
• Put in place a contingency plan for unscheduled or unplanned tasks

 

When a project schedule is slipping, a Project Manager can use a schedule compression technique as a preventive measure. This technique simply refers to methods used to shorten the schedule, without changing the scope, but may include adding additional resources to get the task done or moving some activities in parallel to another one.

 

3. Get the right people for the right job

A project’s success is dependent on the team\’s effort. It is critical that every member has a well-defined role and that they are held accountable for certain project goals and benchmarks. Here are several guidelines to picking the right team members:

• Best fit for the role: Seek team members who have the knowledge, ability and skill to fill the role’s requirement. When such a person is not available consider an enthusiastic junior who could be trained.
• Best fit for the team: Look for committed team members who share similar objectives and goals. But remember that a person who has different views and voices their perspective can be an advantage to the team.
• Connectors: People with particularly wide networks within the organization and who possess good influencing skills are beneficial to any project.
• Communicators: Look for people with good communication skills and soft skills who can unite the team.

 

4. Log the issues

Project issues are factors that hinder a project from its completion. Common project issues are delays in implementation, lack of resources or missing project details. The first step is to identify the issue and its root cause. Next, would be managing the issues based on the following guidelines:

• Create a register to log issues on the project
• Assign a person or a team member to log the issues properly
• Define individual responsibilities for each issue
• Analyze and prioritize issues based on criticality
• Apply actions or corrective measures to these issues
• Monitor the progress regularly
• Pick the right time to escalate an issue
• Propose actions to rectify the issue and assess its impact
• Close the resolved issue and move on to the next one

 

The register of issues and its resolution should then be kept for future reference and learning. This will eventually help other Project Managers especially new hires or junior staff in managing their own projects.

 

5. Communicate, communicate, communicate

Communication is the key to successful project management. Maintaining open, regular and accurate channels of communication with all levels of the project team members and stakeholders is vital. In general, 30% of communication is verbal and the remaining 70% comes from gestures and written methods. The most basic but most important communication principle is to never make assumptions. It is a good practice for a Project Manager to maintain a proper communication plan. The communication plan should consist of the following information:

• Project communication strategy
• The kick-off meeting
• Stakeholder roles and responsibilities
• Project status meetings and frequency
• Change control communications
• Project review meetings
• Transition process from deployment to operations
• Closure meeting

 

Conclusion

Failure can, and does, happen if we do not take precautions and make every effort to keep our project on track. The key to project success is to learn from past failures and take appropriate actions to minimize the risk of the same issues arising again. The failures of past projects are opportunities we can harness to increase our chances of success if we share the lessons learned to all of the relevant stakeholders and other decision makers in an organization. All of the gathered information should become part of a knowledge bank going forward for other projects that might encounter similar issues or problems.

Dr Robert H Schuller, a famous American motivator quoted, “Success is never ending, Failure is never final”. We need to learn from failure, wake up and be ready to improve.

 

 

Sources:

A Guide to the Project Management Body of Knowledge (PMBOK®Guide) – Fifth Edition

Standish Group CHAOS report – http://blog.standishgroup.com/