When I was developing a presentation for the LPPDE conference last fall, I was wondering what metric to use to tie to speed of Development?   I’ve always struggled with the goal of development… even after years in Lean and LPPD!  Yeah, because it’s Innovation, that should deliver top line growth, and if the process of development is executed efficiently it should impact the bottom line as well.  But man, those metrics are so far away from what we did day to day.  They also didn’t clarify the role of development in delivering business metrics.  

In my experience with development, we often got lost in the business churn, the processes or delivering the target product, and lost track of the rate of execution of the projects.  We often forgot that speed to market was critical.  We talked about meeting project deadlines, but holistically we didn’t think about speed when it came to the overall development objectives for the year.

I read, studied, and created development metrics, but they never really jumped out as being reflective of our value to the business. As we know it is difficult to influence without the right metrics which allow us to see change when delivering results (successfully or not).  As lean practitioners know, when we want to influence others the first question we get is why??  “Why do I need to change the way I’m working?”  Over time, I came to answers which contained some combination of the following: “We will solve this problem, This will allow you to work more efficiently” Or, “We will deliver the project objectives we always seem to miss and on time.” Or “We will deliver products which should increase consumer value and ultimately market share.”  But, I always struggled with those answers, they made sense, but they were weak, because they didn’t have a metric which directly connected to the individuals who were asking the questions or to the results of the development team as a whole.  In fact, I never had a leader say, “oh OK, does that mean this metric I’m measuring each month will change?”  I wish a leader had responded that way, then we would have had constructive discussion!!

As I was sitting in Dantar Oosterwal’s session the last day at the LPPDE Conference, it clicked.  I had heard it before, but it didn’t connect until Dantar explained it.  First, let’s start with an assumption: The success of development is measured by the effectiveness by which scheduled projects launch to market on time, deliver the target consumer design or service, and at the target cost to the business and the consumer.  There’s a focus on time which translates to speed here, in addition to quality and cost.   Think about it – How do you measure the success of your Development organization?  Does this match your definition?  If it does, you’re probably ahead of the game.

The way to define this is pretty straight forward, and it’s with Little’s Law, which many of you may have applied in manufacturing, Dantar helped me understand how to apply it to development…  

What this basically says when it’s applied to a development process, is the Projects in the Portfolio (WIP – Work in Process) are equal to the Throughput of Projects/Year (TH – Throughput) multiplied by the time it takes to execute the projects (CT – Cycle Time).  If you think about it, it makes sense…  The ability to predict the number of projects in WIP (the portfolio), is defined by the number of projects executed per year multiplied by the time it takes to execute them.  

However, what I learned from Dantar was to focus on the Throughput because it directly connects to the business results.   Why?  - because the throughput will predict how many projects get to market and  when.  The resulting sales should align with the forecasted sales, indicating the Development Team is delivering successfully (or not) to the business. 

So with the focus on Throughput, the equation looks like:

If Throughput becomes the goal or metric, then Cycle Time and Work in Process (Project Portfolio) become the focus to increase speed to market.    Specifically, if TH = WIP/CT, then

Therefore, applying Lean thinking to reduce cycle time (CT) by 50% doubles Throughput (speed) without adding resources or overworking our teams!   This is important because we cannot just ask our teams to go faster and work harder… hmm that sounds familiar.  With Throughput as the target metric, it is now possible to influence thinking to focus on increasing efficiency of the development process and our teams, and again to not just push them harder.  In my next post, we will discuss options on how to decrease Cycle Time. Now when someone asks, “Why should we do this?”, our response could be ”We need to improve the speed at which projects are moving through the development pipeline.”  If we had been tracking throughput previously, we might say, “Of the projects we executed last year, only 30% of them delivered on time, and because of delays we delivered only 60% of the forecasted sales.”   

What a powerful metric to motivate the development organization to seek ways to improve speed and encourage the adoption of new thinking while defining their value to the organization!