Value Stream Analysis Case Study

Value stream analysis is an examination of the sequence of activities required to design, produce and deliver a product or service. It involves an analysis of way pieces of the value stream interact with each other.  Some of these pieces are:

– The people who perform the tasks and their knowledge and skills

– Tools and technology used to perform and support the value stream tasks

– Physical facilities and environment in which the value stream resides

– Organization and culture of the enterprises which owns the value stream

– Values and beliefs that dictate the corporate culture and behaviors of the owners of the value stream

– Communications channels and the way in which information is disseminated

A current project that I have been working on involves the development of firmware for a communication interface device.  We were moving too slowly and costs were piling up due to delays. Since there were three companies involved in the project (owner, firmware development, server/deployment development) the assumption was that finding improvements would be difficult. That is where I came in.

There are three ways for the businesses involved to shorten the value stream and get to market quicker.

  • Hire or move additional programmers into the development team.
  • Change the management of the development stream.
  • Improve the processes in the value stream.

In this case, adding resources is the easiest to do, the most costly, and least effective means of getting the project done faster. Changing the management structure of the project will only work if the new management would change the development process. The last option, process improvement, is the least costly, maybe the most difficult to implement, but also the most effective solution to the time line and cost problems.

As it turned out, two of the possible changes were made. There was a change in management of the project and the new leadership set out to improve the development process. The chart below shows two value streams.

The top map describes how the development project worked at the time of the changes.  The bottom map describes the new process.

In the former process, there were two review steps to quality check the work done by Tech 1. The wait time between steps was not much of a problem, but the second review step created a huge hidden factory.  There are 60 iterations of this process flow required to complete the 60 different communications functions. Each of the iterations could take as much as 215 hours of time to complete.  That would be 537 work days needed to get to completion. If additional resources were to be brought in, the time lie would shorten, but the overall cost of the project would not change.

The new management team elected to make the following changes:

  • Reassign some of the tasks from the firmware developer to the device owner’s engineering team. Specifically the analysis steps.  This is really nothing more that researching each of the functions ahead of time instead of just prior to the development activities. It also lowered the cost of the project to the device owner through the use of their inside engineers.
  • Combine Tech 1’s coding with the review step involving Tech 3. This moved Tech 3 from a part time asset to a full time asset on the project and had them working simultaneously instead of sequentially.
  • Testing the new code would be done on a local server instead of the production server.  This eliminated Tech 4 from the process until the developed code was finished and tested locally.

The result was the empowerment of Techs 1 and 3 to write and review code without the involvement of the deployment team. Coding errors and other unforeseen issues were caught earlier. This made these problems quicker, easier and cheaper to fix.

Another result was the device owner getting out front of the development with research on each of the 60 functions weeks before the project reached those milestones. This effectively moved 8 hours of cost and time from each of the 60 iterations.

Overall, the new process uses 105 hours for each of the 60 functions. The new time line became 262 work days. Between the use of internal engineers and the reduction in work hours, the cost savings was $800,442 dollars.

Old                         New

Work Days          537                         262

Cost                       $1,565,892           $765,450

I will not say that everyone is happy. Delays and finger pointing have damaged the relationships between the owners and the developers. This will not be changed easily. On the other hand, getting the device into a commercially viable state will make everyone happy. The sooner the better in this case.

One major take away from this exercise is that even a simple application of value stream mapping can make a difference.  Never assume that there is no opportunity for improvement.