Information technologists and software developers do not know best. We are not the definitive experts on what software systems to build. Simply building the software right is not enough. It has to be the right software.
I see too many projects dominated by IT or R&D. It often starts innocently enough. The technologists come up with an idea and implement a software prototype. They demonstrate it to the potential business stakeholders, who are impressed. There is a consensus to move forward and build the software system.
Sounds good, right?
So the technical team carries on until they reach a point where they have something that the target group can try out. (This often takes months, which doesn’t help matters.) The software is deployed into a test environment and a limited group of people are allowed to use it.
Inevitably, as more people get involved, more ideas are generated — some of those ideas will be in direct conflict with the work already completed. This is where things begin to go wrong.
The target group wants to change some aspects of how the software operates, how it looks, and how it responds. The technology team has become attached to the current implementation and resists significant changes. The battle lines are drawn. The project may wither and die or it may proceed after a long, drawn-out political battle. Both outcomes look and feel like failure.
Where did things go wrong?
The software developers built the software right but they didn’t build the right software. This situation didn’t have to happen. The project went off course at the very beginning. At the outset, the technology team should have built a quick and simple mockup of the software. This could have been as simple as a wireframe or they could have used a GUI design tool to create a more polished model.
Either way, little time would have been expended and no one would have become overly attached to the end result. Once approval was obtained to continue with the project, an executive sponsor and a core group of stakeholders should have been selected (hopefully, they would have self-selected).
Then the combined business and technology team could have defined requirements or stories, specified the target users, and established goals for a minimum viable system. This collaborative approach makes people feel valued and engaged rather than dumped on and manipulated.
How do you approach new software initiatives? Let me know.
photo credit: Dean Terry via photopin cc