The Big DIP
Lately, I have had reason to study the effects that Design-In-Process, DIP, has on the profitability of software projects. It turns out DIP is a project killer, and potentially a corporate business killer too.
What is Design-In-Process? It is partially finished work. Most software development projects have too much of it. The manufacturing industry learned decades ago that too much inventory was a bad thing. In the software development business, the inventory is Design-In-Process. We still haven't learned the lesson.
Why is DIP bad? Let's have a look at the classic Return On Investment (ROI) equation:
ROI = (T - OE) / I
Where:
If a requirement changes after it has passed through the process, well, since the customer has already accepted the implementation of the original requirement, the requirement change is ground for asking for more money. No problem. (Except possibly for the customer, who wasted money by asking for the wrong thing in the first place.)
If the requirement change comes when the requirement is in process, it can get expensive. The partially implemented code must be removed, which takes time. Then the new requirement must be implemented.
Developers know that doing this is a real drag. It is boring and time consuming. Project managers don't like it, but since it is not their own time that is wasted, most don't think very hard about the effects. Most project managers don't even know how much DIP there is in their projects, have absolutely no idea what it is worth, and consequently do not know what changes to the DIP costs.
This, I am afraid, is probably true of most agile developers and managers too.
How much money are we talking about? Most project managers encourage developers to work at full capacity all the time. When there is a bottle neck somewhere else in the process, this means DIP will build up. My experience is that there almost always is such a bottleneck. Common culprits are testing, or the delivery cycles may be too long (in which case Sales has goofed).
It is not uncommon for the developers to exceed the capacity at the bottleneck by a factor two or three. That means that if the Operating Expense of a project is 100,000 EUR per month, only about 33,000 EUR gets through the process, and the remaining 66,000 EUR gets stuck in process. It is not uncommon for DIP to continue to build, until all requirements are DIP. All you need for that to be virtually guaranteed is a fixed price contract, payable on delivery...
It is not uncommon for requirements changes to hit the DIP in a big way. Over the past few years, since I started paying attention, I have seen requirements changes that reduce the value of the DIP by 50% or more. One project I worked in had more than thirty man-months worth of DIP, and then there was a change that wiped out all of it. (There was a switch in development languages, so all of the code was thrown away. Please don't ask why...)
If you want to get control of the DIP, there are a few things you must do:
Visible Measurements
An easy, and highly visible, way to measure DIP, is to make a Project Control Board. Use a whiteboard, or a large mylar sheet on a wall. Make a table with one column for each hand-off in your development process. The stages will be different depending on circumstances. For example, where I work, the software we produce will be used in hardware made by another company, so there is a stage where the software is tested in-house with a hardware simulator, and another step where the software is shipped to the other company for testing with their hardware.
Typical stages might be: Requirements analysis, Behavior Specification (if you use TDD or BDD), Coding, Integration Test (includes automated build, and running automated tests), Acceptance Test.
At the start of each iteration, write sticky notes for each story (use case, feature description, or whatever you use). Prioritize the stories, and put them on your whiteboard, to the left of the table you made. It is also important that you estimate the size of each story. I use Story Points, a lá XP. Function Points is an alternative.
Whenever a developer begins to work on a new story, the developer moves the story from the stack of sticky notes to the first column in the table. The developer is then responsible for moving the story to a new column each time the story goes into a new phase of development.
A tip: use different colors to distinguish functional stories, defects, and any unplanned stuff management may throw at you.
Yet another tip: document the board by photographing it each day.
The sticky notes in the table are your DIP. Track it closely. If you have a process problem, you will soon see how sticky notes pile up at one of your process stages.
To calculate the value of your DIP, sum up the Story Points you actually produced in one iteration. Let's say you produced 30 SP. Then sum up the DIP, let's say that is 45 SP. You also need to know your Operating Expenses for the iteration. Let's say those where 30,000 EUR.
You have spent 30,000 EUR to produce 30 SP. That means you need 1,000 EUR to produce one SP. The DIP is 45 SP, so it is worth 45,000 EUR. If a requirements change affects 20 SP in the DIP, your project should write off 20,000 EUR as a loss.
Believe me, once you start measuring, you will see this happen over and over again.
Now, how do you cut your losses? By reducing the DIP as much as possible. That is what I'll blog about next time, probably.
What is Design-In-Process? It is partially finished work. Most software development projects have too much of it. The manufacturing industry learned decades ago that too much inventory was a bad thing. In the software development business, the inventory is Design-In-Process. We still haven't learned the lesson.
Why is DIP bad? Let's have a look at the classic Return On Investment (ROI) equation:
ROI = (T - OE) / I
Where:
- ROI is the Return On Investment, a measure of how profitable a business system (company, project, etc.) is
- T is Throughput, the amount of money made
- OE is Operating Expenses, the money the business system spends producing throughput. Wages, rent, electricity, are all OE.
- I is investment, the money tied up in the system. This includes computers, and furniture, but most of the value tied up in a software development project is usually DIP.
If a requirement changes after it has passed through the process, well, since the customer has already accepted the implementation of the original requirement, the requirement change is ground for asking for more money. No problem. (Except possibly for the customer, who wasted money by asking for the wrong thing in the first place.)
If the requirement change comes when the requirement is in process, it can get expensive. The partially implemented code must be removed, which takes time. Then the new requirement must be implemented.
Developers know that doing this is a real drag. It is boring and time consuming. Project managers don't like it, but since it is not their own time that is wasted, most don't think very hard about the effects. Most project managers don't even know how much DIP there is in their projects, have absolutely no idea what it is worth, and consequently do not know what changes to the DIP costs.
This, I am afraid, is probably true of most agile developers and managers too.
How much money are we talking about? Most project managers encourage developers to work at full capacity all the time. When there is a bottle neck somewhere else in the process, this means DIP will build up. My experience is that there almost always is such a bottleneck. Common culprits are testing, or the delivery cycles may be too long (in which case Sales has goofed).
It is not uncommon for the developers to exceed the capacity at the bottleneck by a factor two or three. That means that if the Operating Expense of a project is 100,000 EUR per month, only about 33,000 EUR gets through the process, and the remaining 66,000 EUR gets stuck in process. It is not uncommon for DIP to continue to build, until all requirements are DIP. All you need for that to be virtually guaranteed is a fixed price contract, payable on delivery...
It is not uncommon for requirements changes to hit the DIP in a big way. Over the past few years, since I started paying attention, I have seen requirements changes that reduce the value of the DIP by 50% or more. One project I worked in had more than thirty man-months worth of DIP, and then there was a change that wiped out all of it. (There was a switch in development languages, so all of the code was thrown away. Please don't ask why...)
If you want to get control of the DIP, there are a few things you must do:
- Measure it! What you do not measure, you cannot control. The first step is to start measuring DIP. To do this, you need to measure Throughput, and you must also measure the build-up of DIP in the development process.
- Make it visible! Neither developers, nor managers, are used to thinking about DIP. The idea that it costs money is strange to most of them. You need to make the DIP visible in ways that are impossible for people to ignore. (Some people will continue to ignore facts, even when they are staring them in the face. Just hope that none of them are your bosses.)
- Reduce it! You can do this with a variety of techniques, either based on Kanban (XP), or Drum-Buffer-Rope (Feature-Driven Development). Even though I really like XP, I have found Drum-Buffer-Rope to be the more flexible method.
Visible Measurements
An easy, and highly visible, way to measure DIP, is to make a Project Control Board. Use a whiteboard, or a large mylar sheet on a wall. Make a table with one column for each hand-off in your development process. The stages will be different depending on circumstances. For example, where I work, the software we produce will be used in hardware made by another company, so there is a stage where the software is tested in-house with a hardware simulator, and another step where the software is shipped to the other company for testing with their hardware.
Typical stages might be: Requirements analysis, Behavior Specification (if you use TDD or BDD), Coding, Integration Test (includes automated build, and running automated tests), Acceptance Test.
At the start of each iteration, write sticky notes for each story (use case, feature description, or whatever you use). Prioritize the stories, and put them on your whiteboard, to the left of the table you made. It is also important that you estimate the size of each story. I use Story Points, a lá XP. Function Points is an alternative.
Whenever a developer begins to work on a new story, the developer moves the story from the stack of sticky notes to the first column in the table. The developer is then responsible for moving the story to a new column each time the story goes into a new phase of development.
A tip: use different colors to distinguish functional stories, defects, and any unplanned stuff management may throw at you.
Yet another tip: document the board by photographing it each day.
The sticky notes in the table are your DIP. Track it closely. If you have a process problem, you will soon see how sticky notes pile up at one of your process stages.
To calculate the value of your DIP, sum up the Story Points you actually produced in one iteration. Let's say you produced 30 SP. Then sum up the DIP, let's say that is 45 SP. You also need to know your Operating Expenses for the iteration. Let's say those where 30,000 EUR.
You have spent 30,000 EUR to produce 30 SP. That means you need 1,000 EUR to produce one SP. The DIP is 45 SP, so it is worth 45,000 EUR. If a requirements change affects 20 SP in the DIP, your project should write off 20,000 EUR as a loss.
Believe me, once you start measuring, you will see this happen over and over again.
Now, how do you cut your losses? By reducing the DIP as much as possible. That is what I'll blog about next time, probably.
Comments