If You Measure It, They Will Come (back)
In my Project Manager's toolbox, I always carry the indispensable measuring tape. It's like the old saw (pun intended): "if you can't measure it, you can't manage it". And, there are lot's of things to measure. Overall, there are three areas of measurement, corresponding to the golden triangle of project management: time, resources, and functionality. The triangle is used because it is a symbol of balance and stability; change any one side without adjusting the others and you get a distortion. Just so in a real project: change the timeline without adjusting the amount of resources or the functionality or both and you are either smarter now than you were before (when you built the triangle) or you are a masochist.
Read on to learn more about how I have used the tape measure on my projects .
What you measure and what you do with it varies depending on where you are in the project lifecycle. At the beginning of a project, the big question is: Is this project feasible? Which is another way of asking, Can we afford the fees?! There are always fees involved in a software development project. If you use inside talent, you will have to assess a resource cost usually calculated as an hourly rate. A common mistake is to treat such talent as "free". As my grand-pappy once said: "t'ain't nothin' free, ceptin' tax forms, and you still give it in the end". or was it, "get it in the end"? No matter, you've got to use a cost fee to assess your options and estimate your costs. Just as important as the costs is the early measurement of time, or effectively, the schedule.
During the requirements phase (we call it "Elaboration Phase"), I continuously measure against the Success Metrics for the project. This is key because there are lots of voices, sometimes competing ones, trying to argue for their favorite feature. Every project becomes a target as a way to get something done and funded. So, you have to watch for those sneaky inclusions. The way I do this is to get the major stakeholders to define how they will measure success of the project (called the Success Metrics). This is always interesting and sometimes fun. At first, a stakeholder might say: "oh, if the project is on time, on budget, and on scope". Wrong. That might be a successful project but it is not business success. I want them to think about and declare what will be quantitative evidence that we succeeded in getting the improvements we sought by chartering the project in the first place. Can you say, Business Case? Amazingly, this is a lot harder than it seems it should be. On my current project when I asked this, one of the answers was "Operational Efficiency". Very good - that showed promise. After multiple months, we finally got to answers to how this efficiency improvement would be measured, what the baseline (for comparison) would be, and what a targeted range of improvement needed to be to define success. Whew!
Having this measure of success became key as we sifted through requirements, real and imagined, and weighed options and costs. Those that traced to the success metric stayed. Those that didn't were early candidates for the pile called: "wishful thinking".
One of the other things I measure during the Elaboration Phase is how long things actually take and how much effort it actually takes. One of the hard lessons learned is that we are generally all very bad at estimating development projects. But, this is really not surprising when you stop to realize that we have never built this specific system/application before, using this set of technology, using these people, and in the current environment, platforms, etc.
The reality is that every major development project has a varying amount of unknowns: we don't know how much time it will really take to build, to test, to integrate, etc. So, we want to carefully measure how long things actually take and compare that to our estimates and refine our basis for estimating full construction, the next Phase.
Bear in mind, this is all done in the context of designing mini-development efforts which go from analysis, to design, to building, and to testing. These iterations are like little controlled experiments where our measurements serve as a means to base our real estimate for the development effort, especially for projects greater than 6-8 months.
To be sure, there is more to measure with our measuring tape later on: testing - # of defects, rate new ones open, rate defects are closed, etc. And, of course, we must measure performance of the system under varying and expected loads.
An old carpenter buddy once told me, "measure twice and cut once!" So, like I said, measure it and they will come (back).
(Guest Post by friend and project toolsmith Bob Cimprich)
Posted on Thursday, December 29, 2005 at 06:20PM
by
Larry Cone
in Best Practices, Best of coneblog, Project Manager Tools
|
Post a Comment
Larry Cone
in Best Practices, Best of coneblog, Project Manager Tools
|
Post a Comment
View Printer Friendly Version
Email Article to Friend
Reader Comments