While I was going through Rapid Development looking for the backhoe story for the previous post, I came across the graph above.
Looks familiar, huh?
It’s practically the same productivity-to-time graph as the one in the Satir Change Model.
What’s different about this section in Rapid Development and the Satir Change Model is that while the latter focuses on how to deal with each of the phases of adopting a new tool or process, the former looks at it at a higher standpoint. Namely, it shows one (admittedly obvious) way of considering whether to adopt a tool or not.
Introducing a new tool or process will inevitably lead to a productivity hit. In the long run, however, we can recoup our losses because of the improved productivity due to the tool or process. This is marked in the graph above as Project B. In this case, introducing the tool is a good idea.
When the schedule is tight, like the line Project A in the graph above, it becomes a different story altogether. There is no time to compensate for the productivity lost due to the learning curve. In the end, the project ends up having worse productivity than not implementing the tool at all. In short, using the new tool is a bad idea.
—
As to the experience I mentioned in the previous post, I believe that we were placed in the Project B mark in terms of project length. Unfortunately, as I mentioned in the previous post, we weren’t able to take advantage of many of the features of the new framework. In other words, our productivity line wasn’t able to go as high as the line in the graph above resulting in a low ROI.
