We used to think of product development as one fundamental question; Build vs. Buy. Once a product was conceptualized, a search was conducted to find the most suitable software solutions and a feature point analysis was completed. An engineering team was only brought in to evaluate Buy scenarios and brought in when needed to consider enhancement or integration issues in Build scenarios.
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.
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.