Software Projects, Failure, and You

Most software projects will fail, and fail in seriously spectacular ways. Failures far more embarrassing than the drunken/awkward Techcrunch interview you gave for the consumer facing product this project is invariably linked to.

These technology projects fail, not for lack of technical or product skill, but instead due to an individual stakeholder having undue influence. These individuals are often in this state of implicit power for reasons explicitly unrelated to their technical or business understanding of the problem domain. For example:

1) This individual is on the board

2) This individual is an advisor to the company

3) This individual has a reputation for success and influence that precedes his or her involvement in the new project

4) This individual is considered a rainmaker

In the truest terms, this is not a positive role to have. When the rainmaker would come to town, he would pray for rain (obviously) and it would either come or it wouldn’t. If it came, the rainmaker took full credit, for it was obviously something he did! If the rain didn’t come, it was the villagers’ faults for not believing hard enough. And the cycle would go on in perpetuity. Eventually for most rainmakers, it would rain at *some* point, so as long as this scene wasn’t playing out in a desert or a dust bowl, the rainmaker would live a nice fat fraudulent life.

5) This individual speaks with a confidence and certainty that simply draws in other stakeholders, parties that exert direct influence over other stakeholders, and possibly even those committed to completing the project’s component tasks

If any of the 5 scenarios sound familiar, your project will fail. It will fail because the project’s scope is no longer tied to the success of the company. The success of the project is now tied to the success of the individual, for lack of a better word, “Rogue Stakeholder”.

You’re hoping for rain that will eventually come and then praising the shaman. By doing so, you’ve created some interesting new problems:

1) The rainmaker/board member/confident talker will now be involved in every future project planning session, warranted or not and regardless of their own relative merits, and this will continue happening as long as the company exists.

2) You’ve lost the ear and confidence of the stakeholders that you know the right way to get things done. The rest of your time in this position will be an uphill battle to re-establish the kind of trust needed for autonomy.


How do you stop this from happening? You have a couple of options, some of which would probably result in termination and/or jail time. My actual proposal might be a little strange, but I think it *just might work*.


** This is much easier to track down then it has been in the past

** Visualize how the project is laid out, using time as the primary metric. Make it painfully clear what changing the scope of a project does to the deliverability date.

** Do not leave any planning meeting without having a clear idea of priorities. If the meeting will cut short, have the other stakeholders schedule a follow up meeting SPECIFICALLY to complete this. Once again, provide visualizations that provide extreme clarity around the real costs (human, opportunity, and anything associated) with taking on the pet project’s changes.

** Try not to fall into one of the stereotypes I’ve listed above, and make sure you’re extremely nice, calm, and polite throughout this whole shitshow. That’s why they pay you the big bucks. 🙂