Two Edge Sword
/There are subtile differences in thinking when trying to make a development project go faster. It is important to understand them because they a so very different from one another. I will explore these often misunderstood concepts.
If you can understand the fine line between both sides of the metaphorical sword, you may be able to better understand the techniques we use with teams to deliver innovative products on time. Like most things, they can be used for good and alternatively they can be used to prove the “impossible” can’t be done.
“Good” in this instance means using the collective skill and experience of a team to discover new ways of thinking about a problem in order to accelerate innovation. The solution is usually there (bits and peices in people's heads), it just needs to be discovered. Learning is the result of the discovery process. Faster learning = faster innovation = faster projects.
Most professionals already know the solution to most of the technical problems slowing down a schedule; the trick is to help them discover it, and then to teach them to do it over and over again throughout the life of a development effort. Projects are a series of problems that must be continuously solved in order to be on time.
Know Gap
The first step in project acceleration is to develop an accurate critical path schedule that realistically expresses the risks a team faces to develop a new technology. When realistic schedules are developed by teams, we typically see a gap between the expected target date for market entry and the predicted market entry time, based on the critical path analysis. It is not uncommon for this gap to be 6-12 months or more.
It is hard to determine the gap, because of the pressure on teams to force-fit their schedule inside the expected target time window. Ignoring the truth can sometimes cause people to feel good at the start of a project, but it only masks future problems.
Then why do we want to know the extent of the gap? Why want to know something that makes everyone uncomfortable about the future? Isn’t this going to ensure that the failure becomes the reality, once we acknowledge it?
One side of the “sword” would answer,“We want to know the gap to prove that we are late.” We will use this quantitatively defensible information to validate that it is impossible to achieve the expected results in the expected time frame, “See, we told you so, it can’t be done and the fancy schedule proves it.”
The other edge of the sword would respond,“Knowing the schedule gap early in the project can create a sense of urgency to find technical solutions and/or work process alternatives to close the gap.”
The idea is to use the data to change the way people are thinking about the problem by showing them the drivers of the gap (i.e. the multiple critical paths). This modeling information could be used by the team to simulate alternative approaches to get to the end state; and to identify where technical innovation is required in order to compress the schedule.
Most schedule acceleration is a result of a) re-engineering the way in which the work is done, and b) finding technical innovations that deliver the same expected results (in terms of the minimum viable product functionality) and doing this inside the target time window. We called this the “no-trade-off paradigm.”
We want to deliver a product that meets the target performance objectives and do it on time - by not trading off functionality for time. It is easy to deliver on time if you jettison half the functionality and compromise the performance. This is not what we are talking about, rather it is to do both - on time and with the desired product expectations.
We want to know the gap very early in the project in order to change thinking, and in doing so, the behavior of the team. We don’t want to use the information to validate failure, but rather use it to influence people so they think differently about the problem in order to discover new ways to doing the work to achieve the stated project goals.
When this is done right, you can use it to drive innovation on a project, early, when there is still enough time remaining for it to have an impact on the schedule. Most technical innovation results in schedule acceleration, because the time pressure forces new thinking/clever ways to solve the problem faster. At the end of the day, if we can’t close the gap, then kill the project and use those limited resources on a project that has a better cost/benefit ratio - value to the business. Cut your losses sooner than later.
Challenge Assumptions
We are often faced with projects that are “stuck.” The team has worked very hard to close the schedule gap and has had some success. For example, on a project that had a 6 month gap to the target date, we saw the team work for 3 months during their weekly Refreshes to take time out of their schedule. They had measurable success early, but then after getting the low hanging fruit, they ran out of ideas to close the gap. They leveled out at 4 months late every week when they ran their Wigglechart.
There were some that expected the project trend to push back up when they hit some of the technical problems they hadn’t yet found solutions for. Few trusted the two month pull-in since the integration phase was coming up and they knew they would have to push the schedule out to get the time necessary to solve those problems.
The solution was to challenge the assumptions they had about the project. Our objective was to use the challenge process to discover new ways to do the work, while at the same time we did not want to compromise the product functions they were expected to deliver. We had to find a way to get the right product done inside the target time window. Wrong product (i.e. de-featured) at the right time would have been considered a failure.
One assumption involved a specific new high risk technology being developed by the team. They were developing it because even though it was risky, it promised to deliver substantial performance improvements that would make the product competitive. It was also thought to be a building block in a technology roadmap that “must” be developed in this project. Using it was “non-negotiable.”
Challenge
They Challenged the Dominating Idea that the new technology was the only way to achieve the performance objective. When they asked, “Could it be done differently?” they determined, through a lot of multi-disciplinary discussion inside the team and with the stakeholder functions, that they could use a combination of existing technologies and a new mechanical design to compensate for the expected performance loss. The solution also involved development of new firmware and modified SoC.
The net result was 5 months taken out of the schedule, a much less risky development effort, with the added benefit of a major cost reduction in the COGS (cost of goods sold). Since COST reduction was the primary project objective, the new solution to save time actually saved even more in product costs, greatly improving product profitability.
The alternative edge of that sword would have been to use the Challenge to validate that the new technology could not be delivered on time. That in fact the only way to deliver the new technology was to extend the schedule, making the first point (Know Gap) a self fulling prophecy. “You now see, we told you we didn’t have enough time and the schedule proves it; and if you want the new building block you should relax the target date so the team does not feel badly about delivering it late, further, since our performance bonus is tied to being on time we would like the target date changed to reflect the new expanded schedule prediction.”
Change Thinking
In both cases, knowing the gap and the challenge are mechanisms we use to change the way people think about the problem. Since both are formal methods/processes, it provides the participants with the “permission” they need to openly explore new ideas; to present reality in terms of risk… reflected as a schedule gap, and then to challenge current thinking assumptions about the technology/project without fear.
Most innovation occurs when conventional thinking is changed. It is hard to change that thinking because of the pressure to conform and validate decisions made above the people that have to execute them.
It is important to use these tools wisely, since they can be misused to prove and quantitatively validate that something cannot be done in the time people expect it to be done.
We want to make sure that players in the game don’t think that the reason we want to know the schedule gap is to justify lateness, and the reason to challenge project assumptions is to justify delivering a feature-lite product.
We want teams to find solutions without defaulting to making the easy trade-offs. This is what defines creativity and what drives right-product, right-time performance.