Transitions
I had a few press calls this week, and there’s a topic that came up several times: transitions.
I think most of us know what a transition is. They exist everywhere, but they’re particularly tricky in the software world. Every time information is transitioned across people or groups in an IT project, there’s a very good chance the information will get lost or changed. It’s like a game of telephone tag.
Some common transitions: developers build applications according to requirements. However, the requirements are rarely defined by the developers (which isn’t “bad”; it’s typically “good” and necessary). This creates a transition. The problem is that 1) no matter how much time a team spends on requirements or which tools they use or which methodology they practice, the requirements don’t always match what the users really want or 2) the developers – even if they’re in contact with whoever wrote the requirements – don’t have enough context and sort of guess at what the requirements mean. The outcome: the developers create a system that matches the requirements as written but doesn’t match what the users had in mind.
Fortunately, lots of really smart people spend time thinking about this, and, as a result, IT has made solid progress in either minimizing transitions or minimizing the likelihood of data loss/change in transitions. There are simple things like making sure you have smart people working on the project and making sure the people writing code understand the business value of the application and have an opportunity to speak with the subject matter experts. Documentation solves a lot of confusion during transitions. Prototyping doesn’t necessarily minimize data lost in transitions, but it helps make sure teams don’t go to far down the wrong path, so I’ll count it. Minimizing the number of outside firms you work with during an IT project helps minimize transitions. Small teams of versatile people help minimize transitions (less people = fewer transitions). There are lots of other examples…as well as lots of opportunities for improvement. Like so many other things: tons of ways to make it better, but no silver bullet.
So, a piece of advice to software teams: minimize transitions on your software projects.