BRETT COLBERT -- STORY OF A PHOENIX PROJECT
/
Not all TOP Management stories start with a success. Technology projects can develop a life of their own, sometimes to the detriment of what is best for the organization and the individual teams involved. Brett Colbert, now VP of Enterprise Architecture at McAfee, gave me a great example from his early management career at Cisco. This is a story of how it is much more difficult to kill a project than to make the adoption decision -- but when the killing is done well it can demonstrate an example of TOP Management by all involved. This is a story of how people and organization/management are tied to the heart of technology development, death, and resurrection -- A Phoenix Project
Brett's story:
A mentor suggested that Brett take on a new assignment: eContact. The project would give him a bigger role and broad visibility given the diversity of sub-teams involved.
Brett's story:
A mentor suggested that Brett take on a new assignment: eContact. The project would give him a bigger role and broad visibility given the diversity of sub-teams involved.
I started doing some analysis and saw that pretty much every category related to general project management was broken or in the red: Quality component that's being managed - No; Code being saved with source control - No; Right level of exec buy-in or change management - No. After about 2 months I went back to Andy [the mentor and overall manager] and said, "Each individual problem is solvable, but altogether it's not. It's a death march and we're way off course." Andy replied, "I was afraid you were going to say that, I agree with you. A rare occurrence, but we have to stop."They were 20 Million USD into this project at the time.
If you were talk to each person individually they'd say yes, kill it. But when you brought people together there was this strong desire to meet the culture of stretch goals that's embedded at Cisco. People could not resist but to say, "We can fix anything! We can do anything!" Even the most rational people, when you tried to put the breaks on things, pushed back -- even though deep down they knew it wasn't fixable. It was a big epiphany for me in terms of the desire for people to be able to prove or stay on course with these incredible stretch goals. They lose the ability to judge what's reasonable, what's impossible, what's stretch [doable, but challenging].Generally when management scholars talk about "escalation of commitment" it's to say that tons of good money was thrown after bad (think Denver Airport baggage handling system). Not so in this case, though it wasn't easy:
It took eight weeks to put the breaks on it... with a lot of analysis. Went back through the criteria that make a good project. This is where it got politically challenging. You want to be honest of how bad things are but you don't want to focus on the people. The people are trying their hardest. You don't want them to feel bad. We built a lot of collateral around why we were red in so many places. We'd over stretched as a company, group, team. What was more important than finding a scapegoat was doing a reset. Tried to separate the people from the failure.... They were busting their butts, giving up holidays. Generally the team was doing what it was being asked.Next came a request to present at the World-Wide IT Managers' Conference. Brett's boss said, "This is such an awesome example of success." Brett replied, "I just killed a 20 million dollar project...." Boss, "Get up in front of 500 IT managers and tell the story of how you killed this thing." Brett gave presentation and says his friends still laugh about it. Remember, this is at the beginning of Brett's career. The amount of support from management was critical. They said, "you never learn when things are going great." Smart management.
Ironically, a year later, after rebuilding their reputation, the same team went after the same problems -- structured it right from the beginning. Focused on all of the lessons learned: starting off with change management, managing scope, exec support. Hugely successful. They will harken back that those were some of the greatest days: On time delivery, camaraderie, hitting stretch goals.I asked Brett, "Given that most escalation of commitment stories end badly, what would you say made this one different?" His answer was the aforementioned management support and the follow-on:
Ultimately jumping back into the same problem and solving it: Having the right people, right roles, right player position.... You may want so badly to solve problem X, team may want to take it on, the business is there -- but if you don't have the right people stop until you do.... If you don't have an org change management plan, it really isn't the individual contributor's problem. If you haven't managed scope, it really isn't the individual contributor's problem.I opened by saying that this was an example of TOP Management by all involved. It was a technology project with all the risks of technology projects everywhere: scope creep, complexity, etc. What made it TOP Management was the clear understanding that the problems weren't about the technology. The problems were about the goals (organizational issues) and extreme motivation and commitment (peoples' responses to the goals). Killing the project required being about to see all three aspects (technology, organization, and people) at once -- seeing that there was no hope given the three aspects as they stood -- and making a tough choice. Resurrecting the project was also TOP Management. The basic technology goal was still sound. Managing the organization and people issues with the lessons learned from the first go-round tied the process together. More on Escalation of Commitment: I'm always looking for examples of success or failure that demonstrate the tight ties between technology, organization, and people. Contact me directly or post a comment below -- I'd love to hear your story.
