Search Blog

8. Value Stream Mapping

This week I finally did my first Value Stream Map exercise in this environment. It took me almost two months to get here. And it only happened because I insisted and succeeded to convince some of the Firm’s project managers to join me.

Ideally, I would have brought in some of the key personnel at the JV too. But there, they were not ready yet. Not nearly. Their idea of Continuous Improvement seems to be linked to doing yet another awareness session for all personnel, to engage the leadership in lean management training and to train trainers for continuous improvement within the organization.

I really prefer to just start DOING lean. I don’t quite understand why so many lean colleagues seem to think that it’s essential for everybody to know all about lean, to experience pull in a lego simulations, to visualize flow, to play around with Japanese words like jidoka and poka yoke, before they ever start improving. To me, there’s just no need for that. Lean comes down to engaging in the habit of continuously improving processes. That can simply be done by asking:

What did we set out to accomplish?

What did we accomplish?

What prevented us from achieving what we wanted?

What first steps should we take to get closer to accomplish what we want?

When can we see the results of that?

Doing so, led the Firm’s Project Managers to conclude that they wish to be able to conclude around 25 projects per year. In practice, they currently don’t complete more than 8 projects per year. They couldn’t tell why. So, then we were ready to do a Value Stream Map (VSM), just to check what the process is actually doing, what waste can be found and how a redesign might be helpful to eliminate this waste: In order to indeed be able to move to the delivery of 25 projects per year.

VSM

We blocked a full morning with all disciplines at the Firm side of the coin. (Not three days, as we were used to do some years ago.) Then, we set out to go through the steps of the process, one by one, writing each of these down on a sheet of A4 paper, including the name of the team member or role delivering this step, the number colleagues who can perform the same role, the lead time, the process time and the percentages of incidents after the step. The key is to distinguish only at the level of handover -and to go through this process quickly-. Lead time by the way is defined as the time the project is sitting idle on someone’s desk, process time is the time that actually someone is doing something (be it valuable or not).

Lean factor

Soon the wall was filled all over. We found a process flow of 20 meters, with a couple of junctions and parallel lines at different points in time. We concluded that an entire project would last 85 weeks to be concluded (lead time). During these 85 weeks, value would only be added during 288 hours. The lean factor was 1,7% (288 hours / 85 weeks). Or, in other words, work was lying idle for 98,3% of the time. That’s not a good score. We then analyzed what would be causing this. We noticed that specialists were often waiting for each others input, sometimes for several weeks. We also found that many reviews, checks, edits and versions were done over and over again. One of the hardest things to accomplish, appeared to be finding an appropriate moment to meet every player at once. Since this was never accomplished, professionals would meet in pairs or in threesomes and then present their results to yet another specialist. Who might not be aligned, upon which the two or three would have to review again. And so on. This was further aggravated, as many specialists would pick up another project while waiting for the contribution of a colleague. Some colleagues were found to work on as many as 25 projects simultaneously. Each time a professional would dive back into a particular project, she would lose a lot of time to first remember the details and the key points.

Redesign

Looking at the detailed process times, we saw that actually the entire project consists of no more than five steps: A global project plan, a detailed project plan, purchase orders and preparation, construction and testing & adjusting. If one needs to do 25 projects per year, then it’s necessary to deliver each step every two weeks. So, having established that, I then asked if the team would find ways to complete these steps within two weeks. It looked no more than feasible to them. If every team member would be liberated to work on only one project and one project stage at a time, they should be able to deliver the product within two weeks. This seemed true for all steps, except construction. Construction might take 4 weeks. So, we thought we could accomplish the task with just one team for each step: For the project plan, for detailed engineering, for purchasing and for testing & adjusting. Construction might have to deploy two parallel teams, in order to deliver two projects in a month (which is equivalent to one per two weeks). It seemed very feasible. But we didn’t know! Besides, most steps were not performed within the Firm, but provided by the JV. So what to do? We decided to just go for a trial run. To try to deliver a Project Plan in only one week time, that is, generously within the two weeks boundary. If we would be able to do so, then we might go to the JV and ask them to do the same!

Delivery

We presented these results to the Firm’s management and asked for support to run a trial of a Project Plan in 1 Week. The management frowned and said yes. This was important, because we knew that we would need their full support. The concept sounds very simple. Yet to accomplish the objective, it requires all specialists to lock themselves in a room with their colleagues, for a full week. And not to allow room for other project demands… While the temptation to allow time for other appointments on other projects was huge. We decided to do proper preparation for this Projet Plan in 1 Week, to do a round of communication to all specialists and to plan for an evaluation of this experiment right upon completion. Also, we scheduled substantial time from some key people in the week after the pilot week, in order to make Standardized Work Instruction -just in case the experiment would succeed-!

Waypoint is project management software to support the execution of Lean and Agile projects, in software development, new product development, construction, Waypoint is software to support lean project leaders and teams. The software allows to budget, plan, report, standardize and improve project execution, along the principles of Lean Project Management and Agile Programming and Planning. Waypoint is offered by Heyunka, a provider of on-line tools for the implementation of lean management and agile development.Heyunka's tools are web-based and require standard compliant browser. Clients are charged only for actual usage -from one to as many users as you like and for as long as you need it. Tools are sold on-line. No IT needed.