Information Technology

<p>More often than not, I see organisations choosing speed over quality when it comes to selecting and deploying a new enterprise-wide business application.&nbsp;</p><p>Whilst fail fast is common in start-ups (where injected capital seems to be endless) and new speed to market consumer products (where competition is fierce and loss of consumers is fatal), this strategy often fails within internal organisations.</p><p>This is more likely to be driven by a burning platform, i.e., software/hardware has already reached the end of life and collapse is imminent (i.e. act fast now) or rising costs are deemed unacceptable by the CFO.</p><h2><span style="font-size: 14pt;">Considerations While Selecting Enterprise-Wide Business Application&nbsp;</span></h2><p>End solutions should always be driven by end internal business user needs based on efficiency and business value. The business outcome should always be the focus.</p><p>You may say that this needs to be balanced, i.e., costs, quality and pace. Internal solutions cannot avoid a fail-fast strategy; internal users will not tolerate broken solutions that impede commercials, productivity and work-life balance.&nbsp;</p><p>The value of a CIO/CTO is to influence at the board level (do they have a seat at the table? that's a discussion for another time), ensuring the correct approach is undertaken.&nbsp;</p><p>Slow down!&nbsp;</p><p>Careful consideration of the options is vital.&nbsp;</p><p>Building internally, partnering with a reputable solutions provider or buying a commercial off-the-shelf product are typically the three options to evaluate.&nbsp;</p><p>These three options tend to drive from the front before the needs are fully established or assumed without proper evaluation.&nbsp;</p><p>Here's where we need to slow down the process and pivot to the business needs. Again, this is where the CIO/CTO needs to take the helm and ensure this has the proper focus.&nbsp;</p><p>The end solution should not only be driven by business needs (with the end user at the core), but the entire business process needs to be optimised and standardised where possible right at the beginning.</p><p>Time spent in this area is well invested time.&nbsp;</p><p>The business community should be determining and driving the needs. The business needs to be driving the entire program. IT is a partner (hopefully of choice). Making sure the approach and focus are correct is where IT needs to influence; this is a skill many IT folks need to acquire and build upon.&nbsp;</p><p>Yes, it will take longer and frustrate the budget holder, but ultimately this will save time (on re-implementation of poor solutions) and cost (deploying twice).&nbsp;</p><p>Be slow, and be cautious with reasonable expectation setting. The role of IT is beyond bits and bytes; if it wishes to be seen as more and more valuable, it must be business-aligned and outcome-focused.</p><p>&nbsp;</p><p><span style="font-size: 10pt;"><em>This article was contributed by our expert <a href="https://www.linkedin.com/in/daltonmichael/">Michael Dalton</a>&nbsp;</em></span></p><p>&nbsp;</p><h3><span style="font-size: 18pt;">Frequently Asked Questions Answered by Michael Dalton&nbsp;</span></h3><h2><span style="font-size: 12pt;">1. How do I ensure my business engages and owns the project?</span></h2><p>As almost all projects end (or should end tangible business benefits, you can then measure these benefits against the business's desired outcomes. This can be achieved by linking the project's success to the business departments or individuals' annual G&amp;Os. Of course, this will not all stack up if the business case is not valid or approved at the beginning.</p><h2><span style="font-size: 12pt;">2. Why is partnering IT with the business so vital to success?</span></h2><p>This is important because a good technology partner understands or should understand the core business and mission. This results in an easier translation of business need to technical delivery. This should be built upon expertise, trust, and confidence in business partnership alignment.</p><h2><span style="font-size: 12pt;">3. But if we use agile project methodology, we can afford to develop flexibly and quickly and correct mistakes as we deliver sprints, can't we?</span></h2><p>Yes, whilst agile deployments with iterative sprints can obtain speed, with enterprise solutions requiring end-to-end workflow quality, this approach often fails due to eroded confidence with too many post-production deployment fixes. In fact, in the end, this will cost more time. Waterfall may be, in fact, the best method for such large-scale solutions.&nbsp;</p><p>&nbsp;</p>