How Asking What If Could Predict Your IT Project Curved Balls
I have a new favourite way to pass free time.
It's a webcomic called "xkcd" by Randall Munroe, an American cartoonist, author, engineer, scientific theorist, and the creator of the most addictive website ever! Especially the site's "What If" column, where Randall attempts to scientifically answer outlandish, hypothetical questions sent to him by readers.
Questions like 'what if what if you tried to hit a baseball pitched at 90 percent of the speed of light?' It turns out that not only would it be hard to hit a home run but as air molecules would not have time to escape the trajectory of the ball, the resulting thermonuclear explosion would take out half the city. Randall explained more on this in his 2014 TED talk.
"What If" got me thinking ... if it's possible to work out what would happen if all the rain from a thunderstorm fell as one huge drop then surely it's possible to predict the consequences of events within the life cycle of an IT Project.
Indeed, when an IT Project fails or hits a significant challenge (one hat impacts delivery or budget), there is usually a post-mortem logical explanation. Late delivery, for instance, could be traced back to scope creep ... you can usually identify the exact stakeholder request that caused the project's timeframe to buckle.
Surely, something that is so obvious and logical in a post-mortem could be predicted or identified in a pre-mortem ... Couldn't it? Hindsight is a wonderful thing but 'what if' you could develop foresight?
As far back as the 1980s, researchers found that through 'prospective hindsight' you increase your capability to forecast the reasons for outcomes in the future - by imagining that an event has occurred and all its consequences. In their 1989 work "Back to the future: Temporal perspective in the explanation of events" Deborah J. Mitchell, Jay Russo and Nancy Pennington suggested that this could be by as much as by 30%! It seems there could be a lot of potential in managing those IT Project "What Ifs".
In the September 2007 issue of Harvard Business Review, Gary Klein writes, "A pre-mortem in a business setting comes at the beginning of a project, rather than the end, so that the project can be improved rather than autopsied. Unlike a typical critiquing session, in which project team members are asked what might go wrong, the pre-mortem operates on the assumption that the “patient” has died, and so asks what did go wrong. The team members’ task is to generate plausible reasons for the project’s failure."
Astro Teller, captain of Google's moon-shot factory X, spoke passionately about the concept of pre-mortems in a talk he gave for Stanford's Entrepreneurial Thought Leaders series in 2016. At X, teams imagine (in some considerable detail) that a project has launched and predict what could go wrong. Then, depending on the likelihood and seriousness of the problem, which is judged through a mechanism whereby the team votes up or down the highlighted issues, the organisation can be proactive and take steps to stop the hypothesized events from happening.
I've seen these "pre-mortems" work spectacularly well. Your team is assembled and told to visualise that the project (upon which they are about to embark in real life) has failed. They are then tasked with listing all the reasons why they personally and independently believe this would have happened ... especially those things that they wouldn't usually flag (because of workplace politics or for fear of stepping on someone else's toes). Often, within these predictions of doom, lie some nuggets of insight. Insight that can forewarn you of potential challenges and banana skins. A great example of this was a team who identified that a potential reason for failure could be that their competitor launched a similar product. They imagined their response, they became more innovative and as a result are about to launch a far superior product than the one that they had been planning.
Other IT Project teams have mitigated against future potential failure by developing a relationship with a Project Management as a Service partner. They future-proof their projects because, whatever happens, a seemingly bespoke and ready-made patch is available on demand. The secret here is that, although you may never have encountered the challenge that is threatening to sink your project, somewhere else on the planet ... someone else will. They will also probably have found a solution that you can use. A great PMaaS partner is best placed to access the market and find that solution giving you the ability to meet head on whatever is in your future. If it turns out that your problem is truly unique then the PMaaS sector has some of the most innovative and flexibly minded talent available ... I'm yet to find a problem to which there isn't a PMaaS solution!
'Prospective hindsight', the pre-mortem or managing IT Project "What Ifs" sounds like such a good idea ... it makes you wonder why more project teams don't invest time and energy in this area.
Research psychologist Gary Klein suggests "many people are reluctant to speak up about their reservations during the all-important planning phase. By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success."
X's Astro Teller talks about creating a culture where individuals feel safe to raise a hand and flag potential issues. He says, "If you get thrown under the bus ... (if) people go after you about it. If our culture isn’t one that rewards you for doing that, that’s the last time you’re gonna do that ... the hard part is relentlessly and repeatedly chasing down those moments where it’s not working. He needs a hug if he said something brave. I mean a physical hug, an actual hug or a high-five or whatever. Then if he actually gets a hard time from someone for having written that down, what are we all gonna do to defend him."
Few businesses have that culture. I know of one company that actually boasts about this in their mission statement, it's literally painted on walls throughout the building and the subject of a screen saver on every PC. However, the number of people who have "left the business" soon after flagging up a potential failing has created a culture where those remaining stay silent and safely below the radar (especially if it's a potential management failing they're flagging). A far cry from Astro Teller's hug!
Another reason that teams don't do it is that there's never a good control experiment. You could identify a potential problem, mitigate against it happening and when that failure doesn’t happen you don't know for sure whether it might have just never happened in the first place. It's kind of like a plot from Doctor Who or Back To The Future!
What I will say is that the team I referred to earlier could have easily countered their concerns about "What if a competitor launches a similar product" with the question "... yeah, but what if they don't?"
Actually, in this case, they'd have been right. Their rivals are way behind and nowhere near launching a similar product. They could have rested on their laurels and brought the original product to market ... it would have been OK. However, asking their 'what if' question made them raise their game. The difference is that the original product would have satisfied the market but the more innovative one (borne out of the 'what if' thought process) will disrupt it.
So, in conclusion, great culture and great relationships may be the cornerstones of how to predict the unpredictable. Try asking "what if" and let me know if you start to see around a few more corners. If you then need some inspiration to help deal what's round those corners ... what if ... you give me a call?