I have already written 2 articles and given an interview about project estimation because fair estimates are an essential question all project owners are concerned of. I really hated to watch the interview after it was published - first because of my horrible accent and second because my understanding of estimation refined since the video had been recorded.
The good news is that now I myself have a better understanding of what is called "fair estimation". I feel that I can share my vision with project owners and give them quite good insight on how to "read" estimates provided by their development camps.
More than a collection of features
Many clients ask to provide a breakdown before starting a project. They assume that a project is a set of features; hence the developers can split the whole work into user stories, estimate every feature separately and calculate the number of days needed to implement the entire project.
Those who have read my previous articles about ERP know why the statement above is not true. A usual procedure of launching a business management software consists of a) development, b) integration and c) feedback. So, development work (which is often mistakenly considered a merely technical thing) is only part of the big picture. Moreover, this part constantly changes depending on the feedback.
If you ask your developers to break the entire project down into features, they will do that. But can it be considered a fair breakdown? No, it cannot as it does not contain integration procedures (which have significant influence on the timing) and does not take into consideration user feedback.
A fair breakdown
There is a much better way to learn the work scope. Since there are three major activities in every project, an indicative breakdown should refer to all of them. From my experience, it looks very natural when a breakdown consists of development cycles, for example:
- Contracts (establishing relationship between retailers and suppliers) - 2 weeks;
- Price management and retailer order creation - 4 weeks;
- Order finalization and invoicing - 4 weeks;
- Order management reports - 4 weeks.
This type of breakdown looks like a roadmap and is easier to comprehend. Besides, it allows adding and describing integration procedures in between paragraphs. For example, after the first development iteration called 'Contracts' the project owner can invite retailers and suppliers to the application so that they could create their profiles. After the second release ('Price management'), retailers are able to see actual pricing and place their orders online. It means that the project is to start providing value to its owner only 6 weeks after it is kicked off!
Can this plan be considered fair? In any case it is much better than the usual "breakdown into features" because it is closer to reality: it is a) easier to understand, b) refers to integration work and c) helps to see the point in time when it brings some value. However, it does not take into consideration user feedback.
Metaphor of four trees
13 years ago I was a professor assistant at a University. I was involved in scientific research work related to using artificial intelligence in expert systems. My supervisor helped me to build a research plan and introduced a rule of four trees.
Imagine a man walking down the road. There are four trees along the road. The man can see the first tree - its size, leaves, species - clearly. The second tree grows farther and is behind the first tree, so it is not that visible. The third tree is much farther than the second one, so the man can hardly see it, but he knows that there is a third tree. The fourth tree is impossible to see from where the man is located, so he does not even know that there is a fourth tree down the road.
The man is to walk past the trees one by one. Every time he passes by a tree, the next one becomes closer - hence more visible.
The supervisor told me to itemize the research plan starting from the first tree and move to next trees when they are more visible.
It is easy to see that the metaphor of four trees is applicable to ERP development. In this metaphor, trees refer to development cycles (iterations) while their visibility is closely related to the overall project scope which becomes clearer as feedback is received. In other words, user feedback is what makes trees visible.
Since there is only one tree completely visible at first, there is a sense in itemizing the first release - 'Contracts' in our example. Two weeks is an amount of time which is easy to break down into user stories and still keep the plan easy to read. The development camp may also specify what kind of feedback is expected after the first iteration to reveal the second tree.
As we have noted, my vision of estimation is closer to a plan or a roadmap rather than to a traditional estimate that has a table with numbers. Not only is the roadmap closer to reality, but it is also more informative. It contains a diverse information and allows the project owner to think of the ways to arrange the integration.
But let us talk about magic numbers that are often provided by technically minded developers. If you ask the development camp to provide "a ballpark estimate" - they will do that. But how is one to understand what they include in the estimates?
Usually, they rely on some principles. If they are agile software developers, their principles assume:
- Readiness of the staff of the company being automated.
- Exhaustiveness of provided information.
- Simplicity of the workflow and design.
Bear in mind that these principles exclude all external factors that may have influence on the estimates. This is why initial estimates are usually lower than the actual time. The developers do not include imperfection in the estimation. They do it for a reason.
Handling the estimation
From time to time, I encounter project owners that ask to include external factors in the estimates. They may get quite unhappy when estimates change as the project goes on and tell something like, 'I asked you to include all possible factors in the initial estimation and hoped that you would be professional enough to do that'.
Once we had a client who concluded all conversations with a phrase, 'If you have any questions, I am always here to answer them'. After every change in the estimation (which was part of a normal agile process) he complained, 'Why didn't you ask me about this before? I told you I was there to answer your questions'!
These examples show that some customers do not expect initial estimations to change. It usually happens when they have limitations either in budget or in time, so they want to know the timeline beforehand. They may consider the estimation unfair if it changes at a later stage of the project.
What I would like to explain is that an estimation based on the previously mentioned principles IS fair. On the contrary, an estimate that includes "all possible factors" or requires too many additional questions is not fair.
If we included some "possible factors" in the estimate, it would not be fair in our own eyes because such factors are out of our control. Having insufficient information, we would need to multiply our assessment by a certain "magic number" - but would it be fair?
If we asked too many questions, it would lead to spending much time on communication while a fair estimation should be done on the spot and refined only when it needs to be refined (at least this is what the agile approach says). Also, asking additional questions may have influence on the project owner's vision and even lead him to some doubts in abilities of the development camp.
A much more professional way to estimate a work scope is to do it immediately after a new information is received without thinking about anything that is out of discussion. What is not provided should not distract the developers just as if it did not exist.
This is my third posting about project estimation and I do not mind to write three more articles. The subject is inexhaustible. This time I wanted to focus on how agile estimations are made and what they cover.
Development camps, since following the agile methods, use special rules and principles to provide predictable estimates. It is essential for software engineers to understand their clients, but professional clients need to understand their engineers too. So they may want to know these principles in order to have a better collaboration around estimates.
If a project owner transfers all responsibility for external factors, additional questions and similar things to the development camp, it may put the developers in a defensive position. They may start multiplying estimates by a certain coefficient and spend time on asking unnecessary questions. It is more productive when a project owner allows the development camp to focus on solving problems and learns how to handle their estimates.
There is a closely related subject I have introduced but not explained yet. It is a principle of simplicity which is essential to solve problems. This principle calls for a detailed explanation that I hope to provide in the next article.