This is my third post on #NoEstimates; the other two can be found elsewhere in this blog. I participate in the Twitter-based conversation although the format is not conducive to detailed exchanges.
I did receive links from participants invested in #NoEstimates; thanks! I did also receive offers to discuss the matter over Skype; I declined these offers because I like to review the background of a subject before I engage in conversation and because I believe that the written form is more appropriate to disseminating ideas because of the wider audience it supports.
This post is based on my review of the links I received. I will not name sources because this is not an attack on #NoEstimates or its proponents. It is merely an opinion piece.
The main argument behind #NoEstimates is that estimating is hard, imprecise, some even say wasted time. This is a bit of an over generalization; building a house is a project that can be estimated down to a dollar amount plus some contingency. The future owner receives this estimate mostly through a fixed price equal to the estimated amount, plus contingency, plus a profit margin for the contractor. At some level, the same can be done for IT infrastructure projects. Software projects are trickier; clients could ask for a fixed price, although most don’t because of imprecise requirements and going fixed price brings in the specter of scope control battles.
Now, imprecise requirements and unforeseen interactions between requirements make estimating difficult. Agreed, but perfect precision is not what we are looking for here. Reasonable people or organizations can and will live with imprecision. In most of my work, clients are happy with a +/- 25% estimate for preliminary budgeting and +/- 10% for tracking purposes. Tracking a project is a bit like flying a plane; you leave from a known location and you land in a known location but what happens in between requires constant, but simple, adjustment to compensate for interactions between the
plane and its real-time environment. Very rarely does it go all wrong if you check how you are doing against the estimate. When that happens, don't assume the estimate is right; find what is wrong.
I believe that most #NoEstimates proponents are or were in the Agile camp and one of their concerns is with the imprecision of Epic/Stories/Story Points estimation. I personally believe that any estimation method, Agile or not, that assumes that past behavior is an indication of future behavior is very faulty. Most projects are not deterministic; even if they were, some parameters could not be controlled because it is not economical to do so or because a parameter cannot be directly measured. Again, we have some estimate and some imprecision. The plane would still fly.
One of the points made resonated with me and I believe would get the nod from most experienced project managers; estimate in small chunks (my wording). If you attempt to estimate a big deliverable without breaking it down into smaller tasks you are going to get into trouble. My take is that in an Agile project, multi sprint stories are probably a mistake; in more traditional approaches, it is a bad sign when you see a task with a duration and effort that spans multiple reporting period. I’ll state that this warning does not mean that you should not estimate; how else would you know that the task or story is that big?
I have a feeling that in some cases we are comparing apples to oranges. I work on contract. I used to work for a company that executed contracts for clients. Some people are staff members of an organizations. When you work contract you are an expense, when you are a staff member you are part of the fixed cost. When you are a staff members your employment (hopefully) transcends your project; when you are a contractor…
Many organizations have their staff members execute internal projects; how long the project is depends on the scope, priorities (other projects), how many resources, etc. If a company is willing to lets the end date slide because of staffing or priorities, there is not incidences on cost; you pay staff anyway. You have budgeted their salaries. They may end up sitting on their hands because of all kind of reasons, same cost. Throw too much at them and you become resource bound; same cost. Why estimate?
This is very different from contract work, when you use contractors you want to know how much and by when. Some colleagues were working for a client that changed its mind on an almost daily basis. That client had a retainer for my colleagues; my bosses loved that client, do I hear the words cash cow? That client would have been better off hiring staff. Or asking for an estimate which would have
revealed that the scope was badly, badly, badly undefined and not .
Most of the input I received about #NoEstimates took the form of arguments from authority. Now,
arguments from authority (believe me for I am an expert) are good only in those making them truly are experts. In this case I am not in a position to ascertain that. The same type of arguments arise when your environment is very specialized; if you are the only one doing something specific, you are a de facto expert and what you say is the state of the art.
Some on the input had numbers but the person providing those numbers acknowledged that he had a small dataset. He also asked for other to share their data. The data is anecdotic but there is an attempt to improve on this. As data becomes available, everyone will be in a position to determine if there is something to #NoEstimates and/or to make refinements.
I remember a client that had developed a pharmaceutical product at great cost; a single treatment was necessary to cure a particular illness. That treatment would cost about US$ 7K, saving weeks in the hospital ($$$$). The product was abandoned because only some doctors knew which patients would benefit from the treatment and none of those doctors could explain how they picked those patients. Basically, gut feel.
I think that in its current state #NoEstimates is at the gut feel level. Hopefully, supporting information will surface, allowing project management practitioners to evaluate the approach and its fit to their projects.
This is the last post on this subject for a little while but I’ll monitor how the topic evolves. Personally, I am far from comfortable.
What do you think? As always questions and comments are welcome.
Connect with me on LinkedIn. I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.