UT football coach Darrel Royal once said “Three things can happen when you throw the ball, and two of them are bad.”
The same is true when you build software: You can succeed, fail, or come up short – two of them are bad. Unfortunately, the majority of software projects fall into this last category where they go way past deadline, cost a lot more than estimated and wind up short on features.
How can you prevent this? It’s really not that difficult…
Step One: Engage the stakeholders! You would think this would be obvious. I can’t tell you how many times we’ve been brought in to rescue a failing project only to discover that the end-users had not been engaged in the project. Shockingly, there have been more than a few occasions where the stakeholders have told us that no one has ever asked them what they need!
There are many reasons for this. Sometimes it’s autocratic management – “They’ll do what we tell them to do, and they’ll like it!” More often the project is started with good intent; by having an initial meeting or two; but over time, user/stakeholder participation wanes. This could be that from the stakeholders’ perspective, the meetings are tedious and boring. Or, it might be the indecipherable nature or the sheer volume of the requirements document.
Regardless of the cause, projects that don’t engage the end users frequently and consistently throughout the development effort are far more likely to fail. Even if the users have to use the final product. Without stakeholder buy-in, the quality of the data, job satisfaction and productivity all suffer.
Next up – How to engage the stakeholders.