Does A&D Inhibit Innovation?

For years the standard software implementation approach was to spend weeks asking the business users what they want from a system, documenting the findings, designing solutions to this and building applications to suit. This is notoriously very costly, inhibits flexibility and increases project risk by placing a reliance on one large investment and longer term returns.

One alternative is Agile, conducting diagnostics up front to build a broad picture of what is required in order to build a high-level estimate for budgeting purposes. This is followed by a cycle of sprints where requirements are prioritised by the business, and design takes place during each sprint along with the build. This approach provides the greatest flexibility, but can be very costly to run and can result in waste, often caused by a lack of discipline on the client side and rapidly changing priorities driven by internal politics.

But there is a third way !

Every business believes they are unique and have special requirements, but the fact is that there are fewer and fewer business processes which have not been automated at some point, and templates often exist to kick-start the process of re-engineering. So this brings us to the third way – Product First. This may initially seem to lack custom focus, but often quite the contrary is true as the “Product” can be either off the shelf software, or packaged templates provided by partners. Any reputable software package will contain a host of features which have resulted from years of business involvement and “lessons learned” from previous projects. So why would a client not wish to harness that experience? Many products such as Microsoft Dynamics 365 offer a rapidly expanding feature set resulting from many years of market insight and customer feedback. Add to this industry specific templates such as the accelerators for Field Service, Events or Project Services from eBECS Ltd. and an enterprise can face a vastly reduced ‘GAP’ to be filled by custom design and development. This results in lower implementation costs, faster implementations and vastly reduced risks, as returns can be realised quicker, especially if a phased deployment approach is taken to bring smaller but faster returns.

So in summary I have several recommendations for modern software projects:

1. Let the users see the standard product first. This will encourage adoption and reduce costs where processes can be updated to leverage previous product investments. This also reduces the risk of setting un-realistic expectations. Often when users are asked “what do you want” they assume that what they have requested will be what they get. This increases costs and conflict later on in the project. Start with demonstration workshops and project team training to show the ‘art of the possible’.
2. Take a phased approach. Consider deploying out of the box first, then identifying gaps where the standard product does not suit business processes which can’t be changed.
3. Adopt an “Iterative Build” approach. Take an Agile like approach by running 2 or 4 week iterations. This can be best split by business process or business area, so that specific business users can be involved in specific iterations.

New technologies can energise business, but old project habits can drain that energy.