Metrics, Part 1

The objective of lean is to eliminate wastes, as waste is seen as the barrier to efficiency and in turn, loss of efficiency reduces throughput and hence profits. Certainly, profit, throughput, and efficiency are terms at least one abstraction beyond what many software development teams are trained to understand. Even the ranks of Project Managers are thin in their understanding how corporate and division profits vacillate given the vagaries of the throughput of their projects. Honestly, even efficiency is a measure that is both more abstract and subjective than most of us are able to clearly understand as a factor of project success.

Therefore, rather than take a top down view at this problem, we can swing around and use Shingo’s bottom up perspective and look simply at the 7 wastes. If we accept his successes at Toyota as validation of Lean, then we can accept that the elimination of these wastes will yield substantive improvements on the bottom line. Induction then states that objective measurements against these wastes become a reasonable view on how to assess progress against the goal of improvement.

Simply stated, if we measure how we are doing in each of Shingo’s 7 Waste categories, we will have sufficient metrics to track our projects both on their own (the lower the waste, the better the project team is able to perform) and against corporate standards.

I do want to note that when comparing a single project against a corporate standard or norm, the team and the process improvement staff must all be of consensus that dramatic aberration (that outside of the statistically acceptable variation) is neither really bad or really good, but rather indication that immediate detailed review must be undertaken. When a project starts reporting data way above the norms most organizations understand intuitively that something is amiss, usually they focus on insufficiencies or inabilities of the team. More likely, variation above the norms means that the team is either (or both) not sufficiently trained in the approach or the domain, or the project objective is not well understood (i.e. it is substantially more complex than the team initially understood). This type of aberration becomes an early indicator that the assumptions made in the project charter are no longer valid. Equally, when a project starts reporting way below the norms, then review is still necessary. Mostly, this type of aberration occurs when the team has over simplified the requirements and the project runs substantial risk of not meeting client expectations.