Modelesis

Like such things are prone to do, the media storm surrounding  Flappy Bird has subsided.  For weeks, the game’s sudden rise to fame and perplexing demise by its creator, independent Vietnamese game developer Dong Nguyen, brought about many theories and thoughts.  Although the matter has seemingly been settled, the loud chorus claiming that @dongatory was incapable to cope with success brought to my mind a question we seldom ask of our own projects, one which carries deep implications: are we ready for wild success?

In Getting Things Done, David Allen advocates a high-ceremony task management methodology based partly on light-weight project definition and management (in his words, “lower-case ‘P’ project planning”).  Anything that cannot be solved by carrying out exactly one activity becomes a project, and you flesh it out in a methodical yet minimalist fashion.   The second step of what he calls “natural planning” entails envisioning outcomes, which includes  envisioning wild success.

The book presents it as an important motivational tool to help crystallize the vision.  However, I think it should also be part of more common and formal project risk management techniques.  Examples abound, especially at the technology architecture level, were wild success brought platforms to their knees: witness Reddit co-founder Steve Huffman sleeping with a laptop to reboot servers overnight; power strips going off at Jeff Bezos' first Seattle home garage as powerful Sun servers processed more and more data for then-nascent Amazon.com; frequent outages at cloud-based services (notably, WhatsApp yesterday, hot on the heels of its multi-billion acquisition by Facebook), among many others.

In fact, I would argue that the technology architecture level cases are the least harmful and are increasingly uncommon.  The openness most technology companies exhibit around these lessons implies abundant information is available on the topic; the high demand for well-managed, highly-scalable cloud services implies a booming workforce of qualified engineers and architects is available (to well-lined pockets, anyway).

But there are many things that can go wrong at the business and IS architecture levels – and they are by no means limited to Fortune 500-sized organizations.  For obvious reasons, many of these failures are much less publicized and known than the big server crashes of “household brand” tech companies.  But they do happen; don’t we all know of an example?  A product launch may be planned; no clear strategy is chosen between a full formal launch and a “soft” or “friends-and-family” launch; assumptions are made that, since a large publicity campaign will not roll out along the product, commercial uptake will ramp up slowly, and some operational corners may be cut; scope is adjusted in order to keep arbitrarily chosen dates, moving critical “alternate” or “exception” business process flows to an elusive, ill-defined “second phase”.  Thus, a product, service or initiative that was otherwise well-conceived and could have provided substantial value to the organization fireballs into a PR and political nightmare, as the growing success of the endeavor dramatically exposes the lack of preparedness for such success – which doesn’t even have to be wild; at times, even mild success suffices to expose serious weaknesses.

The sad, ironic side to all this is that, conversely, we invest so much on  failure planning.  Aren’t we IT types especially famous for this?  Our families and friends think we are freaks, for we are so used to having the inevitable happen and the impossible materialize that we plan to death against every single possible downturn, both on and off our works.

Wild success, on the other hand, remains gleefully unconsidered, waiting to happen and catch us by surprise.  In the midst of the frenzy of your next project, think it over for a few minutes: if you were to experience  Flappy Bird-type success, at launch or six months down the road, would you be ready?