When I was in college there was a systems thinking exercise designed to reduce the number of complaints that were being made about how slow the lifts were in a local office building. We were put into teams to come up with strategies. We were not to be bound by available technology and we could spend as much time as we wanted studying the behavior of the people in the building. On the day the teams presented their solutions they were really very varied. Many were quite were elaborate and took into account everything from tracking how many people were on each floor on any day, tracking traffic patterns, detecting people as they walked near the lifts and so on.
How would you solve this problem?
The point here is that there is an awful lot of preparation, planning, research and design that goes into solving any business problem. Time that has to be spent but not time involved in building the solution.
Time-to-market is the strongest driver in business today. Many of my clients are the largest banks and insurance companies in the world. When a competitor comes out with a new product or service many of my clients have days at best, and weeks at worst, to come up with a competitive response fully supported with a technological solution.
The problem with traditional IT projects is that they require a minimum of set up time before anything gets done. And there is a lot of post-development activity too. All of this fixed overhead delays getting the solution into the hands of the business. I call this minimum overhead a business’s I2Q. Let’s look at this picture.
Everything we have done over the past 3 decades has been about reducing the time from the Idea (“I1”) to the Implementation (“I2”). If we think about some of the things we’ve done they include:
- Off-shoring – 5 developers in India for the price of one at home giving 5-times the productivity … or so the theory goes
- Packages – every possible piece of functionality you could possibly ever want – just turn of the parts you don’t use … a task that is nearly as long and expensive as writing from scratch
- CASE (Computer Aided Software Engineering) tools – paint your application and let the “smarts” write the code … great for simple order entry systems but just as complicated to write as cutting custom code
- SOA (Service Oriented Architectures) – write the basic building blocks of code that represent the business functionality and allow them to be combined and re-combined over time as the business problem changes … except that the reuse promise is being delivered and these services often end up being one use custom code
So what is your I2Q? How can you calculate it? There is a formula:
- Q = 100 / (1 + It + Iw)
- Q is the quotient
- It is the AVERAGE implementation time a project takes – what is the goal time length of ICT projects
- Iw is the AVERAGE waiting time before a project can be started – you can calculate this by taking the length of the backlog in years and divide by 2.
So a company with an average project time of 6 months and an average project waiting time of 18 months would have:
- Q = 100 / (1 + .5 + 1.5) = 100 / 3 = 33.3%
And a company with an average project time of 4 weeks and an average wait time of 4 weeks would have:
- Q = 100 / (1 + .08 + .08) = 100 / 1.16 = 86%
So the drive towards 100% is the goal. What can we do to get there?
5 Strategies for improving your I2Q?
Clearly we can either shorten the project time-frames and/or the time projects languish in the queue. But how can we do this without adding significantly to the cost structure?
- Make projects smaller – smaller projects are less complex, require little or no setup time, can be tracked more accurately, add less retraining overhead and can get solutions in the hands of the business quicker
- Let Pareto rule: 80% of what you need in 20% of the time – focus on the main theme of the requirement, do not worry about corner cases, use this as an opportunity to eliminate exception processes, put the effort into the most likely path through the process
- Develop solutions with co-located teams – communication from desk to desk not email, chat and conference calls accelerates projects – empower the team to solve the problem the way they see fit – just hold their feet to the fire on delivering
- Empower business to develop their own solutions – train the business to use modern technologies for rapid application development that require no programming like the new category of BPM (Business Process Management) tools that are as easy to use as MS Excel and MS Visio
- Don’t use technology when process, organizational or cultural solutions might solve the problem just as well – software is not always the answer
And which solution solved the problem with the slow lifts? The last team to present had the cheapest, quickest to implement and most foolproof solution. They put mirrors on the lift doors. When you’re looking at yourself time passes quickly. Sometimes technology is not the answer.
The Empowering Change that comes from thinking about the overheads in delivering software is that we learn to treat ourselves as we treat the business: as a place where we can eliminate waste from our processes.