Turn Project Failure Into Gold
Amanda Moreno
July 31, 2012 Most of you have dealt with a problem project and all its frustrations–unmanageable personalities, inefficient process, ect. To give you some fresh tips, I recently sat down with CEO, Engineer and Project Recovery Expert Todd Williams on how to turn project failure into sweet success.
K-Exchange: Tell us about your background and how you starting focusing on project recovery.
Todd Williams: I started my career as a manufacturing engineer and then moved into IT. Technology was exciting and fast-moving, but I began to realize that, even at the beginning of my career, people weren’t managing software programs very well. My very first contract was in the 80s, helping Nordstrom manage a software project. Once on the job, I realized that the software was not so much the issue; it was an issue of listening to the customer. When we actually got the application working, IT went bananas! They had tried three times to tackle this project and couldn’t get it done, and all of a sudden some outside contractor stepped it and finished it. That taught me early on that most project failures have little to do with technology or even process, but more to do with the way people learn to work together.
K-Exchange: What’s often the most painful part of fixing a failed project?
Todd Williams: Like I said before, on that first contract project with Nordstrom, IT was not happy when I was able to complete the project. I recognized that the toughest part of fixing a failed project is the political aspect. You have to manage people with bruised egos, people who didn’t want the project to begin with, etc. Project recovery and failure can be extremely political.
K-X:How do you best deal with the office politics? Does this require a good deal of emotional intelligence?
TW: Yes. The first thing you have to do is rebuild the team. When a project spins out of control, you’ve lost the team, almost by definition. People are blaming each other, and people are afraid to make decisions because they don’t want to be held liable. The team is defeated and progress stalled.
You talk to people and find out what their issues are; most people aren’t used to that. Emotional intelligence is huge here, because you are speaking to people from all over the map, culturally, intellectually, and skill-wise. Maybe you have a project with 60 people on it and four of them are going through a divorce, and at least one of them has a family member with cancer. . . If you aren’t paying attention to what people are doing and thinking and how they are communicating with one another, you aren’t going to get anywhere.
K-X: What is often the cause of a problem project?
TW: Here’s an analogy I often use: Take a pen, try to bend it in half. Eventually it’s going to break. Where does it break? Its weakest point. So whenever a project breaks, you really have to look at the support structure underneath it, and say—that’s a weak point, now how do we strengthen it?
Often it’s poor management or poor company policies. I’ve seen a project situation where one-third of the staff didn’t have the skills they needed to do the job.. And it wasn’t their fault! HR had a policy where they couldn’t hire contractors until everyone was deployed on a project. The result? They placed people on the job that didn’t have the skill sets, and HR wouldn’t pay to train them. So of course, it didn’t take long before the project was in trouble.
K-X: What’s the biggest disaster of a project you’ve ever seen?
TW: Two examples come to mind. . .
The first project was a small company, and their problem was top-down. They didn’t have the executive structure to even understand that the project was ill-defined to begin with. We had to bring in sales people, marketing people, financial analysts, and completely redefine the workflow. That was a huge disaster, because we’re talking about a small company that was about to lose 100-150 thousand dollars. That’s enough to break the company!
The second project was in the 10 million dollar range. The company’s development team was in Canada, the customer was in Israel, and there were more development team /partners all over the US and Europe and England. Culture differences and lack of a central control was very damaging here. Not to mention, at the time there were threats of war in Israel (Imagine learning how to use a gas mask on the first day on the job!)
To fix it, we trimmed down the scope of the project, and changed policy so that employees could no longer work remotely—which was terribly unpopular—especially because there was an additional expense in doing so. But, it worked. The people working in Israel went in there and got their work done, because they wanted to get home. Overall, the project moved exponentially faster and communications channels were more fluid. The reward at the end, was that everyone got to go home and we were able to do some really phenomenal stuff—instead of the company losing about 4 million dollars, which is what would have been the outcome had this project failed. ….
K-X: What are some common mistakes companies end up with disaster projects?
TW: One issue is ignorance at the top. Executives need to do more besides ask for reports. Reports are great, but any capable employee can write a glowing report even when things are falling apart. We call those watermelon projects—they are green on the outside, but when you cut to the core of them, it’s all red.
Another huge mistake is when project managers put process above people. The mantra in my company is people—process—and then technology. Managers often think they can execute because there’s a process in place and they can simply check things off a list. Yes, you have to have some level of process. But, what you really need to do is understand people and how you can get them to work together. I just referenced this key principle in a recent post on my blog: We Need Project Leadership, Not Management[TCW1] . If you can lead a cohesive team, there’s no project you can’t handle.
K-X: Can you give an example of how managers can keep people first?
TW: There’s the tried and true method of just walking around the office. Project managers should spend 70 of their time walking around, engaging with the team, or working directly on an issue that one of the team members has complained about. The minute you solve that problem, you have their loyalty and respect—the first step to a much more productive and efficient organization.
Todd recently spoke about problem projects on Knovel’s lastest webinar: Are You Sinking All Your Time Into Float? Download it for free for more great tips! To learn more about Todd Williams visit his website or connect with him on Twitter.
Comments (2)
I absolutely love this blog and find almost all of the post’s to be exactly what I’m looking.
loading...
loading...
I definitely agree that projects need Leadership and not Management. Everyone can be a manager and is his or her own manager but a project needs a leader. Awesome post and blog! This infographic shows some of the issues project managers are faced with http://www.villanovau.com/problem-with-projects-pmp-infographic/
loading...
loading...