Meet Cindy, an experienced program manager overseeing a substantial software development effort with over 100 team members. Her program’s funding was allocated on a solid promise of innovation and efficiency. Delivery is scheduled 36 months from commencement and everything appears to be going fine.
The usual story.
At this point you might expect the usual story about a big software project that’s about to go off the rails. The narrative could easily follow how Earned Value Management (EVM) has been used by Cindy and her leadership to report nominal progress until about 2/3rds through the period of performance. Then, in the final 3rd of the program, the first domino falls when a segment lead blinks in a game of schedule chicken. Successive dominos cause the curtain to slowly unveil the program’s true condition. Stakeholders realize that 2+ years of EVM reporting was pure fiction. The program had concealed poor software quality, low productivity, and fumbled requirements. The software is nowhere near delivery, and the program has been on a trajectory to overspend by 500% since commencement. Cindy will be sacrificed unless she outmaneuvers the hatchet by fixing blame on a supplier. We’ve all seen this story unfold before.
But this isn’t that story.
Nope, in this case Cindy and her team are doing everything right. They avoid EVM, mainly because Cindy won’t suffer being lied to and despises inauthenticity. She runs her organization old-school, with impossible deadlines and tough accountability. She devotes her days to assertively guiding and assisting her senior leadership; and in turn, her senior leaders spend every day on the production floor. Progress reports from the program’s segments are honest, informed, and direct.
Cindy’s success has nothing to do with Agile, it has everything to do with her finely honed leadership instincts.
By conventional measures Cindy is nailing it as a PM. She earned the respect of her senior leaders, who earned the respect of junior leaders, who earned the respect of the specialists on the floor. People have good jobs they enjoy and are producing a good product.
Cindy’s program is running on time, slightly under budget, and the system looks great. The technology appears to be fulfilling its mandate to deliver innovation with a positive ROI. Cindy’s bosses are happy, her senior leaders are happy, her workforce is happy, and her customers are happy.
So, what’s wrong?
The only caveat is that a different group, led by Rachel, could have delivered the same or better value in just 18 months with a staff 1/3rd the size of Cindy’s at a fraction of the program cost.
This raises a question, how fast is fast? Delivering value on-time and on-budget is an accomplishment, but it might not be evidence of excellence. In the absence of competition, it’s difficult to know whether a program is truly efficient. Our jaded IT instincts tend to label program management ‘good’ when it merely averts disaster; and we tend to label any ability to horseshoe a deadline as ‘fast’. This is particularly the case with software projects.
However, when a competitor over-delivers by doing innovation better, faster, and cheaper – the comparison reveals a hard truth about us. It often reveals that we’ve been listening to the wrong critics and measuring our success against the wrong scales.
Unfortunately, for most IT programs – there’s no asymmetric competition and therefore no objective way to define ‘fast’. The lack of an aggressive benchmark is what leads most IT programs down the path of inefficiency and low productivity.
Are you Cindy or Rachel?
In this example – Cindy is good, but Rachel is better. Rachel has the same good qualities as Cindy, but she’s more aggressive and innovative. Rachel would never accept a leadership position over a 36-month program when 18-months is plenty. Rachel would never hire 100 people when 25 will do. Rachel scrutinizes every person; layering her teams, not with good people, but with exceptional people.
Rachel won’t get bogged down implementing 1,000 features that stakeholders claim to want, she’ll focus on essential features she knows will differentiate the innovation and deliver maximum value. For Rachel it’s more about the product than the project.
Would Cindy be Cindy in an organization with Rachel?
In the absence of competition, Cindy appears strong. However, in the presence of Rachael she looks weak. The question is whether Cindy would step up her game if she knew she was competing against Rachel? Would having Rachel inspire more Rachels in this situation?
Think about your own IT organization, are your senior leaders driven to aggressively push the envelope of innovation and efficiency at every opportunity? Are you cultivating Cindys or Rachels in your senior leadership program?
Most organizations in real life would LOVE a Cindy – because most real life PMs are truly awful, and very few IT organizations have ever seen a Rachel. Sadly, the vast majority of software program managers are incompetent. This tips the scales toward lower expectations, causing many CIOs to confuse completion with success; a dangerous association if the organization ever encounters a truly aggressive external competitor.
This slippery slope is how lumbering companies with entrenched and well-defended market positions get outmaneuvered by small nimble companies that smell weakness and opportunity. This is also how Government projects that could easily be completed for under $5 million turn into billion dollar boondoggles.
If you prefer Cindy – you’re the problem
There are several things about Rachel that frighten executive leadership. For example, that little quip about not doing the 1,000 features everyone asks for, and instead doing the ‘right features’. Many executives find it discomforting to trust the judgement of an appointed leader to arbitrate what features are the ‘right features’, especially when a gaggle of subject matter experts is available to establish consensus on such priorities.
Another cause for executive discomfort is Rachel’s need to experiment and innovate. If she actively experiments with how she manages programs, then she’s obviously not following a normal process – and if she’s not following a normal process, how do we know she’s doing the right things incrementally along the way? EVM is comforting, right? Also, what happens if she gets hit by a bus? If the IT organization relies on Rachel’s elevated talent and judgment, then she becomes an irreplaceable cog, which represents a single point of failure. This is quite frightening.
This logic is how executives think, or at least how executives who aren’t very aggressive think. In the end, given a choice between Cindy and Rachel, such executives would vastly prefer Cindy.
However, as with any strategy, the enemy gets a vote. If you choose Cindy as the safe choice, but your competition chooses Rachel – they’ll clean your clock before Cindy ships.
As you hire and promote senior IT leaders, is your goal to stockpile Cindys or Rachels?
Just something to think about.