I’ve been working with several managers at organizations large and small, who want to capitalize their software “earlier.” These managers have some strongly-held beliefs about the people:
- People are resources
- Resources can multitask on several projects at a time
- If “headquarters” does the difficult work, you can move the “grunt” work to lower wage areas and you will save money on the project.
None of those beliefs are true. Their beliefs create a problem for the people, the projects, and the capitalization.
(Note re capitalization: if you expense your product development, you pay all of the expenses (out of the operating budget) as you incur the expense. If you can capitalize your product development, you can amortize that expense over time, showing only the depreciation on the income statement. See Expensing vs Capitalizing for more details. The more a company can capitalize their software, the less actual money the software costs. )
You can’t use normal logic on strongly-held beliefs. Well, logic doesn’t seem to work for me. Instead, I ask them to show me their data.
The form of data I request is a value stream map. The maps expose the various problem(s). This map is a genericized map, not a real client map:
Note a few things about this map:
- The actual work doesn’t take a long time, maybe a day or so. That’s pretty good for story size and flowing work through the team if the team was a real team.
- The wait times kill the cycle time. Assume actual work time is about 8 hours. The wait time is 8 days (at best).
- I might argue that only getting to Staging, not Production, means the cycle time is even longer. (You can’t capitalize until a customer can use the work.)
When the managers see that it takes them over a week to capitalize a feature, they start to think differently. Often, they want to see the root causes.
- Because of the multitasking, whenever one person had to ask a question or hand off work, the next person wasn’t available because that other person was working on a different project. The teams incurred a Cost of Delay due to multitasking.
- The “team” was working in resource efficiency, not flow efficiency. (It’s difficult for me to think of these teams as real teams.) Everyone’s throughput was much lower than it could have been. That delayed the possibility of early capitalization.
- The cycle time was much longer than the team’s original estimate. It’s not possible to estimate with any accuracy when everyone multitasks and hands off work.
The team’s estimates were pretty good for the number of work hours. The problem was all the delays—until the teams created value stream maps, they had no idea why their estimates were so wrong.
The managers were stuck on resource efficiency. The managers had bought the fallacy of the software factory. The managers didn’t realize software was about learning as a collaborative team.
When the managers looked at the cycle time and at the various wage costs, they realize project cost was substantial. They had fallen into the fallacy of thinking that lower wages would mean lower project cost. However, the managers had not included the extra cycle time in their calculations.
They had this stunning realization: it wasn’t the number of people they hired offshore that made a difference. If they hired closer to headquarters, they could reduce the cycle time by at least half. Their increased wage expenses would pay for themselves because of the capitalization opportunities.
The managers had these original assumptions:
- Divide-and-conquer works.
- People are resources. (They’re not! People are resourceful, especially when solving problems. But, people, when they collaborate work together, increasing everyone’s learning. Also, see Thinking About What to Call Team Members and Managers.)
- Moving work to lower-wage countries means a lower project cost. If you can keep the cycle time to a reasonable time, you might be able to do so.
- You can staff a project with small percentages of people, adding up to FTEs, an example of resource-efficiency thinking.
When the managers saw their data, they were open to changing their beliefs.
Until they saw the value stream maps, they didn’t realize that all their management actions worked against their goals.
Your organization might not want capitalization. However, if the managers aren’t getting what they want, consider how to visualize the problems. Here, value stream maps helped everyone visualize the problem.
(Update: the original image had work time both above and below the line. I fixed that.)
| Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Help Managers Visualize Their Problems Opinions expressed by Java Code Geeks contributors are their own. |
