Implementing Strategy
A year back I had commented on the genius of Ross Brawn, when he executed a tyre strategy during raining conditions in Silverstone to help Barichello achieve more than was expected in the British Grand Prix. Yesterday, at Monza the Brawn GP cars on single stop strategy outclassed the rest of the field, despite not being fastest, nor qualifying higher up.
But what does this have to do with IT?
Nearly everything. Apart from the use of technology in taking decisions guided by inputs received through technologically proficient systems, implementation of strategy in a successful manner is important. When depending on IT solutions, it is important to review/ assess solutions based on requirements. Very rarely do we find ready to use solutions. Most solutions, in a corporate environment (and increasingly in personal, as well) require tweaking to suit requirements.
While there are inherent problems in modifying an established solution to suit requirements, the end user should not shy away from that option. It is best to evaluate all options and decide on a solution that would cover all, or most, needs. One can expect to be faced with trade-off options, and should be willing to evaluate all of those before making a final decision. But when evaluated right and with no bias, the solution option that can be adapted is likely to have higher chances of success.
Customised solutions have their own set of problems, but are most likely to meet requirement demands. These can be configured in any way the user, with the sole purpose of meeting results. The best way forward for IT solutions is to decide on a strategy and stick by it. Evaluation and analysis of the strategy would need periodic review but unless something goes terribly wrong it might be better to run the process through it’s paces, to understand who the strategy fared.
Such an approach could appear risky, where costs are the driving factor and risk is high. To manage such projects, short term strategies with smaller task/ project components can be considered. Review of these small packets would allow for modified strategies, with risk mitigation options early on. Such an approach would require higher monitoring and more review hours.
Weighing off the risk against delivery timeline, availability of resources (human and otherwise), and cost, should be part of the initial strategy and should be used as a guiding rule for the IT Project. Finally, clear milestones with expected returns/ outcomes should be decided early on to be used as flags or checks that would be used to evaluate progress and would signal the need for revising strategy.
If all goes well, and the strategy pays for itself, all that would be needed is the time for monitoring, and the pleasure of reaping the benefits – like it was with Brawn GP at Monza.