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.

 

Advertisements

How to reduce waste in IT –Wasted Motion

In manufacturing wasted motion is any movement by a worker or machine in a work space that does not add value to the customer. It includes searching for instructions and tools, retrieving parts, making and modifying parts and rotating or twisting during assembly. Wasted motion reduces efficiency and increases wear and tear which causes injuries and breakdowns.

Since 1900 industrial engineers have made huge improvements in production efficiency by using assembly lines and time and motion studies to reduce the time and effort it takes for workers to do their work. This approach led to the modern industrial era of low cost, mass production, commodity goods.

assembly line

In IT wasted motion is any effort by the IT team that does not add value to an internal or external customer. It includes things like working off old version of documents, fixing defects, creating documents instead of code, deploying software changes manually and waiting for a server.

Wasted effort is ultimately caused by uneven work flow and unreasonable demands.

In Lean production you reduce wasted effort by applying a process called 5S or CANDO. At first this approach doesn’t seem to apply to IT but when you translate it from a physical space to a virtual one it has a lot of value.

5S

Sort or Clean up.

Remove everything not needed in the work space so you can find what you need easily. In IT you can apply this by regularly archiving old versions of documents in your file system and refactoring your software to make it easier to understand and change.

Streamline or Arrange.

Organize your work so that it flows smoothly and consistently without waste, defects or delay. Define your end to end business process from the customer’s point of view and track your work on a Kanban board. Work in small batches. Set up cross functional teams and keep them together. Use Scrum and XP. Use acceptance test driven design and development. Automate software builds, tests and deployments.

Shine or Neatness.

Review your work flow regularly to maintain standards. Build review steps into your business process. Get testers to review requirements and design before you build and get developers to review each other’s code before you deploy to test.

Standardize or Discipline.

Develop common standards and ways of working. Develop and use standard business processes, templates and coding standards. Develop checklists for code reviews and new accounts.

Sustain or Ongoing Improvement.

Use standard methods and continually improve them. Set time aside to write down your methods regularly, train new people in them. Encourage people to experiment with methods and improve them.

The dangers of over optimizing

In the service sector many companies have adopted an assembly line approach to cut costs so they can be more competitive. This approach often leads to a situation where you have to wait a long time for a service only to find that it doesn’t do what was promised and costs more than expected. When you follow up it’s common to get pushed from one person to another with no resolution to your issue and no updates on what’s going on. This happens because it’s possible for one step in the process to reduce costs by cutting staff so much that it increases time and costs for the customer and other steps in the process.

To avoid these problems we need to make sure that when we are reducing wasted time and effort in our own step we increase the value of the end to end business process to the customer not decrease it.

How to reduce wasted time and effort in IT

Toyota is one of the world’s most successful companies with 330,000 staff and a value of $193 Billion.  Toyota leaders often say that their growth is due to the Toyota Production System which is renowned for its focus on removing any activity that doesn’t add value to the customer. Toyota’s method known as Lean Production has spread across the manufacturing industry as companies have realised that they have to adopt it or be left behind.

toyota-model-factory-line

 “All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes.” Taiichi Ohno, Toyota.

In my experience traditional Information Technology groups have a lot of waste that goes unrecognized because it’s not physical.

“The most dangerous kind of waste is the waste we do not recognize” Shigeo Shingo, Toyota

In this series of articles I will translate the ideas of lean production from the physical world of manufacturing to the virtual world of information technology so that you can see the waste in your process and learn how to reduce it.

The cause of waste

Wasted time and effort is ultimately caused by uneven work flow and unreasonable demands.  If we streamline our work and make reasonable demands then wasted time and effort will fall.

IT groups traditionally think of software development as being like building a bridge in which we need to complete each step in the process in one big batch before we move onto the next step. The problem is that software development is nothing like building a bridge and doing work in large batches in specialist groups creates a very uneven workflow which leads to a lot of wasted time and effort and a high rate of failure.

Types of waste

Uneven workflow and unreasonable demands cause several different types of waste. In the language of IT these wastes are:

7Wastes

In the next post I will examine how over production causes waste in IT.

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.

Becoming Agile

Surfer on a Wave

I’m a big fan of agile. I find it’s faster, more flexible, higher quality, lower cost and lower risk than traditional software development. I also find it a refreshingly honest and adult way of dealing with people. But I didn’t always think this way.

When I first started developing software in the late 80’s for a global IT company, most big software projects used a strict step-by-step methodology. We used an approach called Method/1. It came in 20 white binders and was commonly known as methadone because it put everyone to sleep.

Lightweight agile software development methods evolved in the mid-1990s as a reaction against these heavyweight waterfall methods. Kent Becks “Extreme Programming Explained” came out in 1999 but my first exposure to agile was not until 2000 when an evangelical XP coach talked my ears off at a party. His fervor made me skeptical.

A few years later in 2004, I worked at an online jobs company with a gentle, intellectual software architect who thought agile was a good idea and persuaded us all to give it a go. After training we implemented Agile Development on an online project using all the XP and Scrum practices we knew. We had a cross-functional team of developers, testers, a business analyst and product owner, daily scrum meetings, a feature backlog, progressive elaboration of requirements, automated unit testing, continuous integration, a project wiki and burn down charts. To my surprise and delight this was by far the smoothest, easiest and most successful project I’d ever worked on! Ever since then I have been reading as much as I can about agile, lean and systems thinking and implementing an agile approach whenever I can.

One of the main reasons I joined Kiandra IT was because the software development team were committed to implementing an agile approach. If you’re one of our clients, I am convinced that this will give you a much better outcome than the traditional software development approaches you’re used to.