Caught by Surprise by a Sure Thing: Learning from Failure

A number of years ago, while working at a large, successful software company, I took on the role of project leader for what I expected to be a fun, challenging, high-value-add technology project. My sponsors for the project were the chief technology officer and the chief information officer, and the effort was going to save the company $35M in cost avoidance. The technical challenge (untangling a root-ball of legacy web servers and upgrading or decommissioning each one) was the nut to crack, I told myself. With sponsorship from the top and an undeniably strong business case, I blithely sailed into the project.

failcreativecommonsYou know what's coming, right? Things didn't go as I expected. Two things saved the project from being an unmitigated disaster: first, it was cancelled while still in the early planning phase, and second, I was able to learn some very important lessons about project management, and about life. In case they might be helpful to you too, here they are.

The first sign that things weren't going to go smoothly was when my key partner, who was in another organization, didn't engage. He didn't respond to emails, he didn't return phone calls, he cancelled meetings. Then, he told me point blank that "the project isn't a priority for my team". But, but but... I sputtered in my head. Your executive is a sponsor! Of course it's a priority, because your sponsor said so! Lesson number one: Do your own stakeholder analysis, even if you think the sponsor has already smoothed the way. Get to know your key players early in the project and learn what's important to them. I might have saved us all significant grief if I had done so.

Lesson number two came swiftly on the heels of lesson number one: It's never too early to do a risk assessment. Because my initial judgment was that the technical arena was going to be the biggest challenge, I planned risk assessment after the high-level technical plan was in place. And yet, if I had taken a look at the broader project landscape and noted that partner engagement was a critical success factor, I might have done that stakeholder analysis I missed, and therefore been alerted to escalate sooner and with more success.

And speaking of escalation, my third lesson was Escalate with facts. I held back from bringing executive leadership into the conflict because I feared making my partner look bad (he wasn't following his exec's lead, after all), and making myself look unskilled (how come I can't persuade effectively?). I got hung up in the emotion of it, rather than staying neutral and simply reporting on results: emails and phone calls not returned, meetings missed. 

What I didn't know at the time, even though my partner's "it's not a priority" comment should have clued me in, was that his organization was working through the growing pains of being in high demand and under-staffed. His leadership hadn't yet put in place a functional prioritization mechanism, and my project happened to be something the execs wanted but the rank-and-file couldn't deliver. Hence the fourth lesson: Keep the big picture in mind. It's not always about your project; in this case, my project and its difficulty getting traction put a spotlight on a major business process gap. From a bigger picture perspective, my project's failure was an important step in the maturation of the company; a success!

And finally, when the project was cancelled and I felt responsible and upset, I had the opportunity to learn one last lesson: Don't take it personally. Sure, there were things I could have done to have failed faster, with less wasted time and political capital, but in the end, I did my best with what I knew at the time. The sad truth is that projects don't always succeed. My project's failure did not mean I was a failure. It meant I was in there trying and learning, and isn't that what life's really all about?jumpingcreativecommons

What lessons have you learned from project failures? I'd love to hear your stories in the comments below. And if you'd like help turning your project failures into learning opportunities, or want to take the next step toward project management mastery for yourself or your organization, CW Training and Consulting specializes in custom, hands–on, interactive project and process management workshops. Contact us and we'll help you find the right learning solution for you and your business.

What's in a Project Definition?

Welcome back to Demystifying Project Success, a blog series on the 5 key principles of project success.  The first of 5 key principles to any project's success is a concise project definition.  

What's in a Project Definition?

You might ask, why bother with a project definition? It gets all team members on the same page, aids decision-making along the way, and provides something to validate against at the end of the project.  A good project definition communicates goals and outcomes in a concise manner that is easy to understand by all parties.  
Consider three key aspects to a concise project definition:

Easy to understand

A good project definition is easy to understand by all consumers of the information.  Think about well written websites - they are short and to the point.  They are also understandable by a wide range of readers.  The same goes for your project definition.   
Think about your extended audience. Will executives skim the content?  Will poeple who don't work in your department read it?  If so, choose language that is not overly specific to your function. For example, if you are working on an engineering project, be sure to describe it in a way that is understandable by finance and other business functions.  The reverse is true as well.

Appropriate level of detail

Try to keep your core project definition to 2-3 sentences.  Consider the format, "We are doing this project BECAUSE xxx SO THAT yyyy."  The "because" statement is the problem you are solving; the "so that" statement is the outcome you hope to achieve.
In my shed project (that I referenced in my first post), I might write, "I am building a new shed because I want to move my boxes and tools out of my garage so that I can store my car and exercise equipment in my garage."  I could add the target end date, "...by November when the rainy season starts" to make the timing clear.
Avoid a detailed business case or specifics of how you will conduct the project.  If you need those details, put them someplace else.  Do not include them in the core definition. If you have a project that is large in scope, it's ok to go a little longer - maybe a short paragraph for why and a short paragraph for the outcome.  

Verification

Does your project definition provide the project team and stakeholders with enough information to verify the outcomes?  If my goal is to build a shed to store my boxes and tools, how do I know whether I am successful when I am done?  Try to include verifiable metrics in your definition.   If you cannot measure, then come up with something that will help you verify success.  
In my definition for my shed, I said "large enough" to store my tools.  If I were to be more rigorous, I would measure the volume of the tools and boxes, add a little buffer and include the size of the shed in my definition.  If I could not measure the volume, I would know I was successful when I try to move my boxes and tools.  Obviously, measuring would better ensure success.

Get Concise Now

In the end, I might end up with a definition for my shed project that is short, sweet, and to the point.  Not only that, it's easy to say in hallway conversation.  
"I am building a 10x10 shed because I want to move my boxes and tools out of my garage so that I can store my car and exercise equipment in my garage.  My goal is to complete the project before the rains begin in November."
Regardless of whether it is required, write down your project definition.  Say it out loud to someone who is not connected to the project.  This is a great test of whether it is concise and easy to understand. 

Learn More

If you enjoyed this post, please FOLLOW our page and COMMENT.  I would like to hear from you and exchange ideas!  To hear when I publish my next article, please click "Follow" at the top of this page.  If you missed the overview, check out my previous post, 5 Key Principles of Project Success.
If you'd like to delve more deeply into the 5 principles of project success, CW Training and Consulting specializes in hands-on, interactive project and process management workshops, customized to your needsContact Us and we will help you find the right learning solution for you and your business.


Copyright 2023 CWTC ©  All Rights Reserved