Tuesday, 29 March 2011 15:06

Case Study of a Project Failure

Written by 
Rate this item
(0 votes)

Ptimes_Feature_March30Those companies who invested during the last three recessions have passed by their competition who didn’t invest!  If you survived through the recession and are working to leverage the recovery with a few key projects, there’s no time to waste with miss-managed projects – or you’ll see your competition leave you in the dust.  Pay attention to what you can learn from project failure to ensure you’re successful when it counts!

In thinking of good examples of project failure (unfortunately, I’ve seen more than one in my time), I thought we’d discuss a failed company integration program, as it illustrated typical failure points. 

A mid-market manufacturer purchased two companies – one smaller and one larger than itself.  There was a vast opportunity in terms of product synergies; however, it failed to yield even meager results.  What went wrong?  1) Too many chiefs and no Indians.  2) Lost critical knowledge base.  3) Forgot to ask questions. 

1.  Too many chiefs and no Indians – As well-intentioned as the leadership was in terms of hiring experts with knowledge in the acquired companies and with large-company experience (since, clearly, the company was going to grow dramatically in size through the process), there were not nearly enough Indians to implement the millions of project tasks requested by the chiefs.  No program can be successful without considering the scope and complexity of implementation. 

Projects do not fail in formulation; they fail in implementation.  The same is true of strategy.  Therefore, if there are too many chiefs coupled with no Indians, you can easily have the best strategy in the world. While this strategy which should yield significant synergies with huge profit potential,  it can still fail miserably.  Not only did the companies not integrate successfully but customers were lost and cash ran short.

2.  Lost critical knowledge base – Another tempting and normal reaction to planning for the integration is to move people among jobs and change responsibilities.  If handled with expertise, this is fine; however, it rarely occurs.  Even if handled ok, people tend to become disheartened if they perceive the new job as a demotion and/or they have a hard time adjusting to the new situation.  It’s likely their new boss has transitioned as well, and so it can be a tough situation.  Sometimes, they leave.  Sometimes, they end up fired.  And, sometimes they just become unproductive.  All are undesirable results.

For example, in the integration project, the management team hired new leaders, moved employees to different roles and sometimes even to different departments and/or locations, changed responsibilities etc.  They did this in order to reorganize so that the “right people were in the right positions” to support the new organizations.  All done with the best intentions in maon. However, in the end, they lost a critical knowledge base of how the processes and systems worked to support customers.  As a result, although everyone worked hard, customer service levels dropped by 25-50%.

In order to make this transition successful, it is vital to think carefully about who has what knowledge, skills, and history.  Think about your leaders – both formal and informal.  The trick is to utilize the informal and formal leaders effectively to leverage the collective talents of the organization to achieve a successful integration.  Don’t forget about the critical employees who keep things going – shipping, receiving, calling customers etc.  Each person plays a valuable role.  Have you defined how each person fits into the integration plan?   Have you communicated this to them?

3.  Forgot to ask questions – Last but not least, don’t forget to ask questions.  There is no way to know everything required to integrate successfully without continually asking effective questions.  Questions need to be asked of each company, department, and person as the integration proceeds. 

In the integration project, there were so many tasks and issues to address that the executives and project leaders didn’t have the time to ask enough questions.  Thus, they didn’t know we were shipping 50% of our typical volume.  They didn’t realize customers weren’t receiving the same level of service.  They didn’t realize that production was inefficient.  And they didn’t know what the suppliers expected.  Without this critical information, it was easy for the systems to fall apart – and the integration program to fail.

Instead, ask questions.  It’s important not to just ask random, meaningless questions, as that not only wastes time but it will also not help to achieve your goal.  Take the time to learn about the culture, people, processes, and systems, and then ask questions.  Make sure project team members know that you care about their responses.

It is always easy to identify issues with others’ projects (and tempting to tell them all about it); however, it’s not nearly as easy to see or implement on your own projects.  Spend the time upfront to think through examples of program, project and task successes and failures – both yours and others.  What were the root causes of failure?  Ask the project leader.  Ask team members.  Incorporate the lessons learned into your project, and you’ll succeed when it counts the most!

Don't forget to leave your comments below.

Read 6956 times Last modified on Tuesday, 29 March 2011 16:05
Lisa Anderson

Lisa Anderson, President of LMA Consulting Group, Inc., www.lma-consultinggroup.com, is a senior supply chain and operations executive and management consultant. To sign up for her free monthly newsletter containing tips and techniques for improving business performance, click here. She can be reached at 909-630-3943 or landerson@lma-consultinggroup.com

Comments  

 
0 # joe kolinger 2011-03-30 03:12
Lisa - point #3 regarding questions is crucial. So many times everyone wants to look competent so they fear asking [critical] questions. Sometimes it really pays off big to be the "dumbest kid in the class." I once worked on a $35mm project to create an engineering workstation. Nobody wanted to deal with the 'who is the user' question. When the project was completed nobody wanted to use the system. The engineers said, 'this is so simple my aide can use it.' The engineering aide said, 'I'm not using it because I don't get paid an engineer's wage.' There were a lot of very 'smart people' working on this project. But it was badly damaged for a simple reason. Dumbest kid in the class got shouted down. Nice article. Joe www.kolinger.net
Reply | Reply with quote | Quote
 
 
0 # Ted 2011-03-30 03:30
Projects don't fail in formulation, they fail in implementation. I love that quote. I couldn't agree more. Implementation of products that need to be integrated across multiple platforms need an implementation strategy with implementation managers. Too often the PMO or corporate office overlooks the importance of business analysis. Good implementation managers are project managers with a business analysis background willing to grind out the tasks.
Reply | Reply with quote | Quote
 
 
0 # Peter G. Wrisley 2011-03-30 03:55
While it may be true by definition that projects only fail during implementation, it is also true that project concepts set up a tension or even contradictions in goals or constraints with regard to efforts outside the project. In a similar fashion, project assumptions can also set up a project for failure.
Reply | Reply with quote | Quote
 
 
0 # Lisa Anderson 2011-03-30 05:13
Joe, absolutely true! I've found a significant portion of success to be asking good questions.
Reply | Reply with quote | Quote
 
 
0 # Lisa Anderson 2011-03-30 05:21
Ted, I've found that implementation is the 80/20 of any project, and business analysis skills and a business acumen are definitely helpful.
Reply | Reply with quote | Quote
 
 
0 # Lisa Anderson 2011-03-30 05:29
Peter, although I agree assumptions can get you in trouble, I've also seen that excellent project leaders will insist on clarifying faulty assumptions when it comes to implementation. However, there is no reason to set up a project to struggle to succeed - beginning with poor assumptions certainly doesn't help matters. To that point, I've also seen that asking the right questions upfront helps to ensure decent assumptions.
Reply | Reply with quote | Quote
 
 
0 # Asad 2011-04-01 11:53
Not enough right implementors, asking the right questions and experts are the basis of a sound plan but I will say having a governance structure in place to program the execution is essential to ensure all of the above have been addressed by the program teams that are all aligned and cross communicate transparently during this effort.
Reply | Reply with quote | Quote
 
 
0 # Lisa Anderson 2011-04-01 11:57
Asad, I agree a governance structure is another element of a successful project; however, I haven't found it to be in the top 3. Thanks for the feedback!
Reply | Reply with quote | Quote
 
 
0 # kehinde 2011-04-04 20:46
"Project do not fail in formulation, they fail in implementation. " It is pertinent that we take Project Monitoring and control very seriously in whatever we do. It does not matter hw fantastic your plan and strategy may be, you need to know whether it is implementable or not, and this you can do by carrying out constant monitoring and control.
Reply | Reply with quote | Quote
 
 
0 # Lisa Anderson 2011-04-05 05:02
Kehinde, agreed!
Reply | Reply with quote | Quote
 
 
0 # Hashim Rasheed 2011-04-10 20:53
Agree with two points; that projects fail in implementation and we must know the people, culture and processes before asking questions. Response to change and feedback is often influenced by the level of interaction and relationship established between client the two parties. This fact is often neglected, which in turn effects the implementation efforts in an adverse manner
Reply | Reply with quote | Quote
 
 
0 # Jill Miller 2011-04-14 02:44
Great article Lisa! My frustration with project management is unrealistic deadlines. The customer (internal and external) always wants their project completed yesterday. I had a client yesterday that wanted a project completed and deployed by Friday. I told her no, we could not deploy that project in that short amount of time. I talked to her two hours later and she said "so you are going to deploy that project on Friday morning." If we do not stick to our guns and insist on a realistic timeline, the project may not fail but the project will ultimately be late (according to the customer, not the promised timeline) and over budget (because you were late). I would love to see an article about how to be successful when dealing with clients that are always putting out fires. Thanks for your insight.
Reply | Reply with quote | Quote
 
 
0 # Ruperto 2011-05-03 16:24
Know your Client, their culture and yours, know their people and yours, know what is to be solved and define the strongest strategy for the Project. If not, IMPLEMENTATION is doomed before IMPLEMENTAION! I've seen it in too many instances in East Asia, Middle East and Texas, where the common characteristic is inappropriate and insufficient number of staff, not understanding how to get decisions made, and inadequate understand of the tasks, their interrelationsh ips and sequences AND proper time to complete... Good luck to all. PLAN WELL-STAFF WELL-EXECUTE WELL-SLEEP WELL
Reply | Reply with quote | Quote
 
 
0 # Ruperto 2011-05-03 16:27
PLEASE ALLOW ME TO CORRECT: ... IMPLEMENTATION! ... and inadequate understanding of the tasks, their interrelationsh ips and sequences AND proper time to complete... AGAIN, Good luck to all. PLAN WELL-STAFF WELL-EXECUTE WELL-SLEEP WELL
Reply | Reply with quote | Quote
 
 
0 # Ruperto 2011-05-03 16:37
PLEASE ALLOW ME TO CORRECT: Know your Client, their culture and yours, know their people and yours, know what is to be solved and define the strongest strategy for the Project. If not, FORMULATION is doomed before IMPLEMENTATION! AGAIN, Good luck to all. PLAN WELL-STAFF WELL-EXECUTE WELL-SLEEP WELL
Reply | Reply with quote | Quote
 
 
0 # mindy 2011-05-27 06:20
I agree, a thorough understanding from the all levels imapcted by process change to users etc, are critical to be included to add value to the existing process. Many times processes change however it may not take into account all areas or what it required to fix in the first place due to complexity of the project.
Reply | Reply with quote | Quote
 

Add comment