An obvious simplification to the process. But even in a Build scenario, most of the requirements were written and sometimes even estimated before the engineering team had a chance to evaluate.
Now let’s look at some facts (or at least trends)
- The software world is faster today; Teams must deliver functionality faster in order to stay competitive.
- Requirements are more complex covering concerns like security, business continuity, internationalization and many others. And applications typically have more complex integration needs.
- Build vs. Buy are the extremes – the more likely scenario is that a solution requires assembling a number of parts; build, partner, third party api’s, open source, etc.
- Innovative solutions can come from different parts of the organization and leverage examples from other industries.
- Given the scope/on-time/on-budget dependencies, many applications (and I would argue all customer facing applications) should optimize time and budget over scope. Scope can better be addressed by a series of follow on enhancements based on customer analytics and feedback.
How should an organization handle this brave new world? The solution lies in collaboration especially between senior technologists, product management, and customers (internal or external). It lies in developing basic business cases (business benefit, timing requirements, vision on core needs) before detailing product requirements. It means technologists knowing a field of solutions and having the credibility to make recommendations. It means these teams need to work together to define both requirements and solutions. And when you put all of this together internal collaboration leads to innovation.
Leave a Reply