The Scenario: An Unrealistic Demand
While working for a large, rapidly expanding non-profit, I was tasked with upgrading the organization’s technology. We anticipated doubling in scale over 12 months. Adding to the challenge was an already understaffed technology department, supporting antiquated technology. The task was daunting, but we had an amazing team.
My boss, the Chief Financial Officer, set lofty goals. However, a record of successes quickly built the organization’s confidence in our team.
As we neared a critical turning point in the year, an unrealistic demand was placed on me and the team for which I was accountable. The requirement was to replace the primary software tool of the company, in less than a month’s time. I was shocked by the expectation.
The already overburdened technology team had no bandwidth and the CFO would not accept changing priorities of other efforts. A replacement of such a critical tool would typically require months of planning alone. Yet I was being commanded to completely replace the system in a matter of weeks. I refused, insisting instead that we limped along on the antiquated system for one more season.
What Happened: Disaster – Fired
When I refused to support the initiative, I was given two options: do it, or lose my job. Unfortunately, my family was dependent upon my income. I saw no other choice and worked furiously to develop the best plan possible.
Those weeks felt like a scene from a horror movie where the victims run like crazy, but the slowly lumbering assailant remains steps away. I saw no way the project could end well.
As usage of the new system grew, failures increased. Eventually, the system failed completely – a result of poor planning, insufficient resources and inadequate training. Ultimately, I was called into the CFO’s office and asked for my resignation.
What I Learned: You Can’t Lead What You Need
I should have resigned the moment the CFO insisted on the project. I never would have though, given my family’s financial position at the time.
Had I volunteered my resignation at that moment there were two possible outcomes:
- The CFO backed off his insistence: I remained employed there and we addressed the solution properly at a later time.
- My resignation was accepted: The organization had no one to lead the effort and would likely delay the replacement until a later date – when it could have been properly addressed.
For the organization, either outcome would have been better.
Three Lessons
It may have been the hard way, but I learned many lessons from this event, including:
1. You cannot lead what you need: If you feel you need the job you have, it will be much more difficult to lead in that role. Creating a sufficient savings to depend upon in times of crises, building a strong network and maintaining confidence in your ability to find alternate employment will help you lead more by needing less.
2. Build relationships at all levels: I also realized that I trusted the CFO to do what was right. However, he faced his own pressures. Ensuring strong relationships at all levels will help you avoid depending on a single individual (even your boss) in critical times.
3. Always have a backup: I knew the project would fail. Therefore, I should have invested more of the team’s effort in a back-out plan. As Mark Sanborn said in Up Down or Sideways:
“It is too late to add a backup chute once you’ve left the plane.”
This concludes the third and final post on My Great Failures and the lessons I learned. I hope you’re able to learn from my experience and save yourself some of the same challenges.
Question: What other lessons do you see in my failure?
Hi Ben,
I think that a company that forces the PM to commit to an unrealistic schedule and then forcing him to resign when the project ultimately fails is not a company worth working for. By the way, scapegoating in IT projects is an art, and is very common. CxOs do it all the time to blame anything wrong in the company on the PM…
Great to see you again, PM Hut – I always appreciate your insights and I agree with you on this, for the most part.
In this case, the CFO was not transparent with the rest of the executive committee. Therefore, I may have been, at least in part, his scapegoat. However, as a servant leader there was more I could have done. Namely, if I’d built relationships with my boss’s peers, this could have been avoided. Moreover, if I’d not needed the job, I could have refused the unrealistic demand and reinforced the insanity of the request.
You are right though, scapegoating IT projects has, sadly, become an art to many.
Ben, Unfortunate situation yet wow what powerful lessons. Thanks for sharing your wisdom.
I suspect many of us wish we had that foresight when we faced similar unrealistic demands. It’s well worth weighing the options you mentioned before deciding. Many times, as you indicated, we aren’t prepared to opt for other choices because we don’t have the necessary fail safes in place.
Adding to your list, an additional approach that is also worth considering is to submit a risk assessment or risk map to the leadership. When risks and potential consequences are identified and clearly articulated, the entire leadership team will be made aware of the disruption the upgrade could bring given the high likelihood it will fail.
I’ve learned the hard way to lead up by providing a written risk assessment and part of a planing or briefing meeting no matter how little time there is to plan or to meet. What senior leaders do with the information is another thing entirely.
We often aren’t aware of or aren’t in a position to exercise good options for various reasons. We do the best we can with what we know. What’s key is we learn from our experiences, grow stronger and pass on our lessons learned to the up and coming servant leaders.
Another great addition, Mona. I especially like the aspect of ensuring the risk assessment is written. Thanks for contributing this great point!