One of the most puzzling conundrums of modern software is that, even though many software projects are more likely to hit the “big three” of ‘on time, under budget, and on spec’, the products still end up being seen as failures by the organization. This is particularly true for companies that are trying to develop or introduce a wholly novel product.
On the one hand, this trend is encouraging: it means that software processes have started to build things very well; on the other hand, it’s increasingly clear that the processes are not good at understanding what needs building. TUG argues that the failure to produce novel products that match an initial vision is caused by a disconnect between the intent of the organization and the development teams trying to realize it.
Acting without Understanding
This disconnect is a reflection of what current software practices tend to do well, which is to take a small group of business people, maybe only one, to proxy for the business and use that proxy to realize incremental improvements of an existing system. But big changes are not always incremental, so if the next release requires work that is not coding, but some more involved form of analysis, then incremental improvement will fail. This acting without understanding often ends up creating one of three undesirable outcomes.
Outcome I: The Hopeful Monster
The most common problem in modern development. I wanted a unicorn, I got a rhinoceros. It's still got the four legs, and then it's got the horn, and it's a mammal, but it really didn't turn out the way we hoped it would turn out. Like, in theory, it's functional, it just really didn't turn out the way we thought it was going to go.
Outcome II: The Artist’s Colony
Another common problem, especially in fast growing companies or startups. Your development team is just bursting with creativity and innovation. They make things that are really, really cool, but you don't have any idea what you're going to do with it. What is it for? WHY did you build it? Companies can often expend huge amounts of effort trying to find a way to make products developed this way actually work for them.
Outcome III: The Trojan Horse
Rigid top-down command structures are implemented in order to assert more control over a project. The changes don’t address the core issue with incremental change, and add a lot of management expense to the project. They also has the side effect of demoralizing dev teams and affecting retention. In the short term, this added management layer adds an illusion of control for organizational leaders, but it ultimately doesn’t affect the core problems of the software development process, which is that deep understanding hasn’t been established BEFORE the development process started.
Understand, then Act
If we see these patterns in our organization, what can we do as product managers or executives? Well, the first thing is to acknowledge that new product development is hard; it requires a clear vision as well as the ability to express it, then guide it to fruition.
Second, it’s important to remember that design and architecture shouldn’t be the main job of the development team. Their job is to understand what you want, then make it. They have tools to help gain that understanding but ultimately the responsibility lies with the organization and its leadership. The warning signs described above are the failed attempts to make that innovation cross the gap between vision and reality.
So if you are seeing these warning signs, you may need to fix your innovation gap. The Understanding Group’s IA Staycation teaches product managers and team leads how to make sure that you are properly describing what you need to your development team. Alternatively, if you want to ensure you have the tools to communicate your strategic plans and align intent throughout your teams, check out TUG’s Modeling For Clarity Workshop.
Of course, you can always just contact us and we’ll describe how TUG makes sure that understanding precedes action!