As a kid, I recall watching the Jerry Lewis Telethons.  To my surprise, I understand that the Telethon continues to this day, but I haven’t watched one since I was a kid. The Telethons are always successful in reaching their goal, yet they only have a fixed amount of time to achieve it: 24 hours, if I recall correctly. 

The Telethon’s success in achieving its seemingly unreachable goal left an impression on me:  I guess because our family was always cheering for Jerry to reach his goal towards this worthy cause, and he always managed to exceed it within the waning minutes of the event.  There’s nothing like wresting victory from the jaws of defeat to leave an impression on someone.

Jerry’s challenge with raising the target donations is similar to the challenges we face in estimating and delivering software projects on time.   He has no way to precisely estimate how much money he can raise in the 24-hour event, yet he has a target, and he always exceeds it.   For all we know, he may be given the target amount to raise, yet he is still successful in achieving the goal.  Similarly on software projects, teams are asked to deliver a fixed set of requirements on a fixed date, but unlike Jerry, we are rarely successful in delivering everything on time.   

How Did Jerry Do It?

Whether Jerry was given a target or estimated the target, he was successful in achieving the goal.  How did he do it?  He did it by rigorous use of metrics.  While I haven’t read anywhere about the technique that Jerry used, I’m certain from repeatedly watching the event that the technique I’m about to describe was instrumental in achieving and exceeding the goal.

• He clearly defined what done looked like.  It was to raise X amount of money in 24 hours.   How many software projects clearly and objectively define what done looks like?
• He broke the larger goal into many smaller goals, repeatedly communicated the amount of money he needed to raise to achieve the smaller goal, and worked to secure the goal.  How many software projects similarly break the project into many smaller goals, regularly communicate measurable physical productivity required to deliver the smaller goal, and have the team work towards delivering the physical goal?
• He repeatedly asked the donors for exact amounts of money.  He’d often say something like, “I need 10 viewers to call in with $100 donations each in the next 5 minutes.”  How many software projects request measurable productivity goals?
• He constantly measured how much he was accumulating towards his goal.  How many software projects closely track the progress of their projects by measuring physical percent complete?
• He regularly communicated to his viewers the progress he was making towards his goal.  How many projects regularly communicate their status using metrics to the team?  Often status is never fed back to the team members; instead, status is often only delivered to upper management.  Status on software projects is rarely delivered using metrics.

Summary

The process is simple:

1.     Identify what done looks like with an objective measure.

2.     Break the big goal into many smaller goals.

3.     Give the team physical productivity goals.

4.     Measure the physical progress towards done.

5.     Communicate to the team the physical progress towards done and what production is remaining to achieve done.

6.     Repeat beginning at step 2 until the goal is achieved.

Communication is paramount, and the communication is clearer with the use of metrics.  With more precise communication, aided by metrics, goals are more easily achieved and even exceeded.

Some of you are likely saying, “software is different.”  But is it really different?  All software development projects produce lines of code, all projects find defects, and all projects fix defects.  These variables are all easily estimable and measurable.  I’ve seen and managed teams who have used this process to deliver on time, with high quality, and exceed customer expectations, and they do it with less stress, less overtime, and more team and individual satisfaction.  To realize the benefits of software metrics, first the software community has to free themselves from their irrational aversion to metrics — especially lines of code.