I think your system is a good one, but generally, any rational approach to tracking of output – consistently applied – will be valuable.

I don’t have the data to back it up, but it seems like I write the most lines of code in the earliest part of implementing something, and it isn’t a linear relationship. The first 20 lines of code may take 10 minutes, and the last 2 lines of code may take an hour. But your point is valid – and if I consistently see that, I can account for it in my forecasts.

Thanks again.

On my own software projects, I have estimated output and tracked output against time with excellent results. My favorite measures are LOC, Defect Count, and Defect Fixed. Before the project starts I estimate LOC and expected number of defects to find and to fix, and then as I execute the project I proceed to track against those estimates and contrast them to effort expended as a percentage of budgeted time.

For those who give this a try, they will find the amount of control they have on their projects to be unsurpassed by any other techniques. The common arguments are that it’s impossible to accurately predict LOC and Defects, but that isn’t the point. The objective is to control your project, and even though the precision isn’t 100%, it still is able to tell you that your assumptions that the project plan is based on are wrong, and it tells you that early so you can do something about it, and thus, control your project.

This one I totally don’t understand, probably because most of my career was in construction where the elements were absolute and subsequently you could estimate with some certainty the percent complete. After reading your article, I don’t understand why I can’t estimate percent complete based on hours estimated vs hours completed? Can you tell me what concept I’ve missed in the article. thanks.

Construction projects allowed larger better understood items, because they had been done for many decades, and as you said – they are concrete deliverables (pun intended). When you pour a large foundation, you know it will take 2 weeks to cure, with a near-zero chance that you will have to tear it up, remix and repour because you forgot to put the rebar in place first. So you can present that knowledge. The foundation might make up 20% of the total build time for a pre-fab structure.

Here are some construction examples that might mirror software development:

• What if there are too many impurities in the water used to mix the concrete? That could delay setup time (and mess up the schedule). And you won’t know until it is too late. When you do a core sample after it “should be done”, that’s when you find the problem.
• Imagine you’re framing a stick-built house. It “should” take 5 guys 2 weeks. What if they are really slow? It takes them 3 weeks. But you don’t get to go on-site and inspect their work, so you don’t know they aren’t done until the 11th day. If you had listened to them after 1 week, when they said they were 50% done with the whole frame, you’d be in trouble. Software is like that – a project manager can’t inspect the code to know if they really are 50% done. Imagine on the other hand, they had 4 days to do the first floor, 4 days to do the second, and 2 days to frame the roof trusses. On day 5, when they said “the first floor isn’t done yet” you would know you had a problem. In construction, the people managing the schedule (almost?) always had the experience to be able to look at the “big deliverables” and decompose them into smaller deliverables. The “use smaller tasks estimates” process was happening implicitly. Can’t do that with software if you’re not a developer. And on large projects, you might not be able to do that anyway.
• When the drywall team hangs the sheetrock and muds all the joints, the finishing team can come in and paint. What if the joints weren’t done well? You have to add time to the schedule to sand and re-spackle. What if a freak storm comes in, driving temperatures down and humidity up? Spackle and paint drying times extend significantly. If your team doesn’t know to bring in a portable space heater, your schedule will slip.

I think the key thing is that you can estimate percentage of deliverables that are complete. And the estimated time for remaining deliverables is the “best info you have.” If you don’t review the deliverables, it would be like saying “this project should take 6 months – therefore after 3 months, it should be 50% done – with no way to confirm it. With construction projects, you have those confirmations because you have the concrete deliverables.

Great question, and thanks for the continued reading!