How to reduce waste in IT – Waiting Costs

article-2255693-16B57A8C000005DC-948_964x647[1]

Waiting costs time and money. When customers have to wait for a product or service they are spending time and resources they could have used for something else. This means that the total cost of a product to a customer is the direct cost plus the cost of waiting. The more time you make customers wait the more expensive your products and services are.

waiting cost2

It’s the same for employees and internal customers. The total cost of a product or service to an organisation is the direct cost plus the cost of waiting. When employees have to wait for the instructions, permissions, parts or tools they need to do their job then the organization ends up paying them to do low value activities when they could be adding value to a customer.  So the cost of waiting comes straight out of profit.

When waiting becomes a regular problem people respond by hoarding which increases cycle time and inventory which increases waste further.

The causes of waiting

Waiting is caused by bottlenecks in the system which are in turn caused by a poor system and by a failure to provide the people doing the work with the information, parts, tools and resources they need.

In command and control systems senior executives usually don’t consider waiting costs because they are too far away to see them and aren’t measured on them. As a result they drive internal and external suppliers to provide products and services at the lowest direct cost even if it causes delays. One of the main ways to do this is to centralise work into large batches and send it offshore to the supplier with the lowest labour costs. The problem is that this creates major communication, quality and alignment bottlenecks which lead to high waiting costs across the organisation.

For example a high quality in-house or outsourced IT team can usually deliver a fully configured and installed test server on site for a development team in a few days for $10K with only a few hours of client input. In comparison a big low cost offshore service provider might be able to do the same thing for $7K due to low labour costs. If you install a lot of servers it would seem like you could save a lot of money by outsourcing it all to one of these big offshore companies.

The problem is that it often takes a low cost provider six to twelve months to deliver, configure and install a test server. For example one large multimillion dollar project that I was involved in was delayed because the infrastructure provider said they would be able to deliver the environments needed in six months and then took nine months to deliver the test environments and fifteen months to deliver production environments. While the team of 80 were waiting they minimised the impact by escalating to management, developing work-arounds and doing any work they could. As a result the project was delayed by six months and went over budget by more than a million dollars which was a lot better than it could have been. This is unfortunately a common experience in large organisations which happens when management don’t count the cost of waiting.

Some other common examples of waiting in IT are:

  • waiting for stakeholders to provide feedback on requirements;
  • waiting for the architecture team to review the design;
  • waiting for management to provide approval to proceed through a stage gate;
  • waiting for management to provide funding for the build phase;
  • waiting for procurement to approve a vendors statement of work;
  • waiting for another team to change a shared component;
  • waiting for defects to be fixed that are blocking a test module and
  • waiting for a deployment window.

How to reduce waiting costs

In free market economies decisions are made locally by the people impacted by them. To these people waiting costs are obvious and serious. When stakeholders and employees can choose between suppliers then they will choose the one that has the lowest combination of direct costs and waiting cost. These decisions drive down waiting costs across the organisation. As a result one of the best ways to drive down waiting times is to push resource and supplier decisions down to the users of those suppliers.

Another way to reduce waiting times is to implement the Plan Do Study Act cycle to remove blockers and streamline your work. That is to: study your process to identify issues causing delays, plan changes to resolve these issues, act to implement these changes and check the impact of these changes on cycle time.

deming_pdca_cycle[1]

 

Control charts are an important tool to help you study delays in your process. Control charts measure the time it takes to complete a cycle of your key business processes for software development and infrastructure delivery from you’re stakeholders point of view;

waiting cycle time2

Cumulative flow diagram’s are another useful tool which helps you identify which part of your process is slowing progress;

waiting cfd

Once you’ve identified the area where delays are occurring you can address it by using the following techniques.

  • Allocate more resources to the bottleneck area to increase it’s capacity;
  • Put in place a buffer before the bottleneck to make sure that it doesn’t run out of work;
  • Stop previous processes from increasing the queue of work for the bottleneck station;
  • Reduce batch sizes to improve flow through the bottleneck;
  • Use daily scrum meetings and visual project management tools such as Kanban boards to ensure that everyone is clear on what they need to do each day;

You can also increase the speed of the bottleneck station by using “Five S” to reduce wasted motion.

  • Remove all steps that add no value to internal and external customers;
  • Streamline the work process to remove any unnecessary effort;
  • Develop Standard Operating Procedures to reduce time and improve quality;
  • Continually improve the standard procedure;
  • Implement reviews and automated acceptance tests to improve reliability and quality;

Waiting is a major cost to organisations that can easily out way any benefits gained from driving internal and external suppliers to drive their costs down as low as possible. To reduce waiting costs measure them, push decisions down to users and implement the PDSA cycle.  This is well worth doing.

 

What’s the evidence that Agile works?

In my experience Agile works very well but it’s helpful to have concrete evidence to convince skeptics.

Case Study 1- Telco Projects

In 2007 I worked on a series of large projects for a large Telco using a heavy Prince 2 waterfall process. During this company’s multibillion dollar IT transformation program, the business and technical people became very unhappy with this approach and in 2010 the COO announced that they were going Agile.

Prior to the Agile announcement my group spent nearly two years using this Prince2 methodology to deliver three large multi-million dollar projects which transformed the company’s online platform for Enterprise customers. As usual these projects took longer, cost more and delivered less than expected.

After these projects were deployed, the business asked us to deliver the most important things that had been de-scoped in the next three months before they lost their remaining budget. We estimated three projects with the usual waterfall methodology and found that none of these projects could be delivered in three months. Since time was short I asked the business, the vendor and IT management to let me use an Agile approach to deliver as much as we could in the time remaining. The result was proof that Agile works.

On the first portal, we delivered the features requested in 50% less time and 10% less cost than originally estimated. On the second portal we delivered the features required in 30% less time and 10% less cost than estimated with half the functionality deployed early. On the third portal we reduced the time it took to place a business order for mobile phones from 10 minutes to three minutes for 80% less than it had taken to do a similar project two years before! This is shown in the table below.

Agile vs Waterfall

Case Study 2- Ericsson Mobile Core

In 2009 Ericsson Mobile Core recognized that their established practices were failing. Projects were delayed. Quality was difficult to maintain. And even with the best project management oversight, they still had problems obtaining a believable picture of where they were.

In Experiences of the Ericsson Mobile Core Agile Transformation Ericsson reported that after a three year Agile transformation they have exceeded customers quality expectations, reduced their product development cycle time and released new functionality ahead of schedule.

Case Study 3 – SAS Agile Transformation

For many years SAS used a waterfall methodology to develop the SAS Platform and implement new solutions for customers; but from 2005 SAS found that they were unable to keep pace with customers’ demands for new features. So in 2008, SAS decided to implement Agile to improve speed to market and trained over 2,000 staff.

In a 2013 paper Agile Adoption: Measuring its Worth SAS reported that teams that implemented agile have been more engaged, more productive, produced higher quality products and delivered faster. SAS found that the return on investment in Agile has been substantial irrespective of project size and length.

The 2011 IT Project Success Survey

Scott Ambler, found similar results in the 2011 IT Project Success Survey of IT industry professionals. This survey is highly credible as more than 80% of the respondents have more than ten years’ IT experience, 51% are IT managers or team leads and more than half are from large organisations with more than 500 people.

The 2011 survey shows that Agile projects (iterative, agile and lean) are much more likely to be successful than traditional and ad-hoc projects. When asked how successful projects were in their organization, respondents said that 67% of agile projects in their organization were successful compared to 50% of traditional projects.

agileevd1jpg

Agile projects are more successful because many more of them deliver a quality system, meet stakeholders real needs, provide a return on investment and deliver on time and schedule. Traditional projects are less likely to deliver a quality outcome and most of them don’t meet stakeholders needs, provide a return on investment or deliver on time.

agileevd2j

Drilling down we can see that more than 70% of Agile projects were effective at delivering a return on investment compared to only 30% of traditional projects.

agileevd3j

Agile methods work. Try it and you’ll see.

If you want some help contact me at Kiandra IT