IT projects are a central part of today’s business world, and it’s vital IT managers use the most efficient methods available to develop high quality business solutions, while managing costs and the level of risk involved.
Previously, some companies have tended to focus too heavily on a rigidly defined set of objectives identified at the beginning of the project, and have used processes which don’t permit the degree of flexibility required to succeed in rapidly evolving business environments.
To help avoid similar fates in the future, this article investigates the elements which combine to create a blueprint for successful IT projects and offers advice on how to deliver the best results.
Avoid the crystal ball
During many IT projects, businesses only focus on one element – the final outcome. Most are occupied with trying to see into the future and predict their business needs ignoring the fact that these are likely to change as the project progresses.
The temptation is to believe that by sticking to a fixed set of requirements, the organisation can minimise the risk of the project spiralling out of control; caught in a never-ending cycle of change requests and scope creep and never actually delivering value.
However, it’s quite normal that during the course of a project, the requirements will change. Sometimes due to external changes in the business, and often because in the course of developing an IT solution, organisations have to define very precisely their business processes. This attention to detail can often reveal inefficiencies and opportunities for improvement. A project which is unable to identify and adapt to changes which are genuinely valuable to the business runs the risk of delivering a solution which is exactly what they thought they needed, months and months ago, but in fact delivers no value to the organisation as it is now.
Flickr is a great example of this. The company started life as an online game with an added image library. However, after trialling the game with the target market it was clear that the image gallery was becoming far more popular than the game. It took a brave decision by Flickr to accept the 'failure' of the game and refocus its efforts on making the image gallery successful.
> See also: The three blueprints for business innovation
A particular kind of change which organisations often have the greatest difficulty in adapting to, is the realisation part-way through a project, that the project will not deliver enough value to make it worth investing in further – that the project should be cancelled. It’s vital that an organisation that wants to innovate is capable of making this kind of decision
To truly succeed businesses need to accept that regardless of any precautions taken, things will go wrong during IT projects, but the most important thing is to respond quickly. IT managers should not be afraid of failure. Leading companies today have adopted “accepting failure and recovering quickly” as key elements of their innovation processes.
Finding out what doesn’t work is often a necessary step on the path of exploring new territory and essential for successful innovation and remaining competitive in a fast changing market. The skill is in learning to fail fast and cheaply – identifying as early as possible that a project is no longer likely to provide a return on its investment, so as to be able to minimise the cost. It’s crucial that organisations don’t regard this kind of event as a waste, but recognise it as a necessary part of the learning process.
Optimising processes and systems to allow failing fast and cheaply demands a subtle change in the way that we design and evaluate them. Traditionally, managers have tended to favour to reduce the 'mean time between failure' – that is, to try and reduce the likelihood of any event that incurs an unexpected cost to the business.
However, doing so can often decrease the projects ability to handle cope with such events, thereby increasing response times and in turn increases costs.
Alternatively, businesses should focus on reducing the 'mean time to recovery' – accepting things inevitably do go wrong, but ensuring quick response times are in place for any faults which arise. This reduces the fear of failure, giving the business more confidence to take choices which carry both a higher risk and a higher potential return.
One note at a time
Suppose one day, inspired by Nicola Benedetti, I decide to learn to play the violin. I could get a copy of the sheet music for Brahms’ Concerto in D major, book the Royal Albert Hall for 10 years’ time, and then start at the first note, and try to work my way through it. But most tutors wouldn’t suggest this approach.
They might recommend that I spend a year or so learning the basics, at which point I might be able to do little recitals for friends and family. Then join a local string ensemble – now I can entertain a few dozen people, and maybe I’ll even get some kind of reward for it. Keep practicing, join an orchestra, go professional, keep working, and just maybe the Brahms concerto will be something I can achieve.
But perhaps I’ll play for a year and then decide that I don’t like the violin after all – I want to switch to trumpet instead. Or maybe after 5 years I’ll decide that I’ve had enough of classical, and I want to go and play jazz, or play the fiddle in a folk band. Either option is fine, of course – but all those people waiting at the Royal Albert Hall are going to be mighty disappointed! Maybe I shouldn’t have committed to such a precise goal so early in the process?
Alas, too many IT projects take exactly the 'Brahms in 10 years' approach – defining an ambitious goal with many uncertainties, far in advance. They then attempt to do whatever it takes to get to that point, without regular communication with the business along the way. This results in the project following its own course and not meeting the business’ changing expectations.
Breaking a large project down into manageable chunks, each of which delivers something of real value to the business, allows IT managers to easily change direction, from small to major changes. Making sure that both IT and the business understand that the eventual target is negotiable ensures that development remains flexible, and lets the business adapt as required.
When a project is in production, developers can communicate more effectively and consider whether they are meeting the final expectations. This way any necessary changes can be made quickly, at a reduced cost and the project is able to stay on track to deliver within budget and on time.
Ultimately, development teams must ensure IT projects can change direction at short notice; a goal that is only achievable through close and regular collaboration with clients and careful design.
Delivering business value quickly
Traditionally when IT projects are commissioned, businesses can wait months or even years for them to be completed without seeing any value added to the business. With today’s business world growing increasingly volatile; market changes often happen in the blink of an eye, development teams must ensure IT projects are delivered in a fast and effective manner. Otherwise business requirements could change and the project may become irrelevant, outdated and potentially worthless.
It is therefore essential that IT projects mirror the technology industry’s development, deploying a 'minimum viable product' – the smallest amount of functionality that actually delivers some business benefit – within an agreed time frame to ensure business value is added early on.
Test, test and test again
An iterative approach to delivering software demands that we take a modern approach to the engineering processes that the project adopts.
> See also: What 2014 taught the CISO about planning a cybersecurity strategy for 2015
If we expect to be repeatedly refining the same piece of functionality over and over as the system evolves, we must ensure that code is optimised for maintainability, and resist the temptation to focus on speed of initial development. Typically, initial development of code in enterprise applications accounts for less than 10% of the lifetime cost of that code, so reducing that cost is often a false economy.
The most important element here is to ensure there is a plan for continuous testing. In traditional IT development, the testing phase is not undertaken until the project is towards the end of its implementation. This not only leaves it open to discovering fundamental problems in the project, it also increases the amount of time and money involved in correcting the issues. Additionally, system testing must be automated, so that as new functionality is added, developers can be confident that they haven’t unintentionally broken existing code.
This approach to testing aids the management of risk within a development, along with ensuring the project is built to a high quality and delivered in a timely manner.
IT managers still utilising traditional software development approaches must update their techniques to remain competitive in today’s fast paced markets. By applying modern day lean and agile principles to software development projects, business value is delivered early, issues are resolved quickly and end products are kept in line with the client’s needs. This adaptive, customer-focused approach removes the fear of failure, reduces costs, ensures high quality and allows businesses to remain competitive in an ever changing marketplace.
Sourced from Chris May, consultant, Black Pepper Software
