There are things you cannot stay sure about, as they are not stable. You might have spent thirty minutes commuting to work today, but what kind of guarantee do you have that it won’t be two hours tomorrow? There are copious factors that might impact your commute experience, such as the route you choose, the time you leave for the office, etc. Sure enough, your morning routine is not the same every day, so the amount of effort you put into making it to work.
Still, we are all adults, right? We all are responsible for our morning routines and getting to work because we know that our punctuality (or the lack of it thereof) can and will impact the work of other people. Nonetheless, no one cares how long it takes for you to reach your destination, right? It is your own responsibility to make it to work on time because your timely arrival or its lack thereof can either accelerate or dock down a project’s progress. Thus, even the slightest deterioration in the software development process can have a noxious impact on the entire project, team, company, or even market.
In accordance with KPMG’s deal tracker, the global value of currently effective contracts reaches the point of $160 billion, with software development being one of the leading niches filled with outsourcing vendors. Now, let’s have a look at the aforementioned example of commuting to work on a wider scale. Imagine your company left with absolutely no information about its employees’ working schedules. Even if the disruptions are not regular, they can have a detrimental effect on the company’s ability to calculate the budget required for the completion of any project.
Yet, let’s acknowledge that the software development effort cannot be calculated by talking about the commute time only; there is a lot of factors to take into account, as this is a complex process consisting of copious factors. Therefore, calculating the time span required for completing any technical task seems to be a bit of a “monkey business” at first sight.
Nonetheless, we’ve got experience on our side, and we can attest to the fact that our project duration and effort reckonings always fall in line with the final result. So, before we share the secret of how we manage to provide our clients with refined software engineering effort estimates, let’s first have a deeper look into how it can impact your project’s delivery pipeline.
Conventional Software Development Pipelines
It is not a secret that the last couple of decades has seen software systems growing exponentially intricate and complex. In fact, there is nothing to wonder about as they are becoming more and more copious. What is more, every single industry has been impacted by software and is now heavily reliant on it. Thus, the very process of software development longed for acquiring a form – a standardized process to follow when it comes to development.
Nowadays, this process – the pipeline the software engineering follows – is called the Software Development Life Cycle. It was crafted to define the main tasks and stages of their completion within the framework of developing custom software for the IT companies’ clients. In his book, Global Business Information Technology, Geoffrey Elliott, a renowned voice in the world of IT, claims that the major purpose of managerial methodology in software development is to provide a deliberate, structured, and methodical approach to developing software while structuring it into independent stages that cumulatively accomplish the process.
If this is a traditional, may we even say an orthodox, software development life cycle that we’re talking about, then there are 6 major stages to mention. They are planning, analysis, design, implementation, testing, maintenance.
The process of developing a project’s roadmap – how it is going to be planned and managed from start to end – is nowadays based on several generally accepted software development methodologies. One of the most stepwise (the step-by-step nature of project development is that both customers and vendors prefer the most) methods, though, is one called the waterfall approach.
This is an approach to apply to properly defined and specified projects. Yet, it should be acknowledged that it works best with projects that are not too complex and require a relatively small volume of work. The projects developed in accordance with this approach are mostly aimed at solving secondary tech and business issues. Also, the automation of a particular internal task might also be a mission for a waterfall project to deal with.
That is, the waterfall approach is best applied to the fixed-price projects, where the effort required is known in advance. In general, a traditional software development lifecycle is pretty simplistic and features a lot of disadvantages. So, let’s start discussing the first one, which is the assessment uncertainty that might emerge in the early stages of SDLC.
A Flaw(less) Theory: No Certainty in Estimating Your Project
The statistic says that seven out of twelve failed projects claim that a delayed delivery causing the cost overrun to be the major problem, eventually leading to failure. Just think about it, 60% of your project’s success is heavily reliant on whether your engineering team’s time and cost estimates were correct.
in his The Mythical Man-Month: Essays on Software Engineering, Fred Brooks claims that: “More software projects have gone awry for lack of calendar time than for all other causes combined.” The author went on to explain that “...all programmers are optimists. … the first false assumption that underlies the scheduling of systems programming is that all will go well, i.e., that each task will take only as long as it “ought” to take.” Yet, engineers are put under constant pressure, and their optimism won’t help here, as, at the end of the day, they come to understand that they are the ones to be held accountable for unrealistic estimates causing unplanned project delays.
One way or another, the clients always consider even the foggiest estimates as the commitments software vendors gave them. They say that experienced engineers live by an unofficial rule of doubling the estimates whenever they’re asked for them. Anyway, accomplishing the project faster will always be better than delaying the deployment. Nonetheless, when the estimates are made too soon, they will always be incorrect, and the “doubling method” won’t help as well. There is a fervent need for proper documentation and detailed specification of the project’s requirements if those are accurate estimates that we’re talking about.
As a matter of fact, there are four major factors to take into consideration when trying to provide a realistic project effort and time estimate.
- In-Depth Specification. Try and gather as much information as possible, as it will let you plan every step with more precision.
- The Stack. Various technologies require different inputs and efforts for dealing with the same tasks. So, knowing what you’re going to work with in advance will help you build viable plans.
- Graphic Design. The more complex from the UI/UX perspective your project is, the more time you’ll need to implement it. So, make sure to define all the design specifications.
- The Experience. Keep in mind that Seniors and Juniors will need different time spans to deal with the same task (if juniors could be dealing with the Seniors’ tasks). Hence, keep your team in mind when providing the final reckonings.
Yet, this is only the beginning, and you should know that the more the project seems easier at the beginning, the more issues you might experience developing it. For example, here comes a simple quote: “I want to log in into the app.” No further specifications needed, huh? Well, here are some alternative variants of what your customers could have had in mind.
- There must be a specific type of login I want them to implement (two-factor authentication, social networks login, etc).
- The login and password must have special restrictions, that is the maximum number and the type of characters to use.
- I’m thinking of the “Remember Me” option, and they will surely add it by default.
- How the app must react to a wrong input? Well, I want the app to let users have four tries instead of the classic three.
- Recovering the password must be easy. I want it to be done via the phone. There’s surely no need to emphasize on this.
You’ve seen it all yourself: one simple feature, which the client can express in one way, can entail a whole bunch of issues. Can you imagine how those uncertainties can deviate you from not only providing adequate estimates but also dealing with the project itself.
That is, you cannot provide a precision estimate during the early stages of the project. You and your clients, you have to come to terms with a statement that the more clear requirements they provide, the faster you’ll be able to answer with an accurate quote.
Have you ever heard of the Cone of Uncertainty? Well, this is a concept that presents the aforementioned phenomenon in a vibrant and understandable manner. Introduced by Barry Boehm in 1981 and further developed by Steve McConnell in 1997. Let’s have a look at it!
The chart above showcases it clearly that the highest level of uncertainty can be associated with the starting phase of any project. Quite often, the starting phase is the planning phase. As you can see, the estimates there might range from 4x to 0.25x, meaning that a project scheduled to take a month can actually take your team one week as well as four months.
Nonetheless, the farther you move into your project, the lower the degree of uncertainty gets. The R&D stage plays an important role in it, as it can bring the estimate’s variability to the minimum. They say that the availability of precise tech and design specifications can decrease 1-month deviation in a project estimate to one week. Yet, let’s acknowledge that the exact duration of every project is subject to the question until the product or platform is rolled out.
This is the moment where we have to acknowledge one thing: the Cone of Uncertainty principle is perfectly applicable in theory. Yet, when it comes to talking about practice, let’s acknowledge that the deviation range is often dependent on the project’s scope. So, if you’re dealing with a hefty, long-term project, get ready to make some “guesstimates” at the very beginning of it. You’ll think they’re of value at the initial stage, but you’ll eventually see that real estimates must be more rigid.
Is There A Method to Choose? Talking About Estimation Tools and Methods
Mapping It Out | Breaking the Work Down
As we have already mentioned, the project’s roadmap is generally compiled by the time the analysis & planning stage is over. Its primary task is to dock the uncertainty effect down and provide a concrete software development effort estimate. In their book, Applied Software Project Management, Jennifer Greene and Andrew Stellman claim that: “A sound estimate starts with a work breakdown structure.”
Well, you might ask what is the so-called work breakdown structure (WBS)? A sound answer is to be found in the PMI Project Body of Knowledge, where the WBS is classified as “…a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables.”
In accordance with this “method,” the work tasks are being broken down according to the Agile backlog, which sees to the completion of measurable and manageable deliverables. The WBS is all about providing a visual representation of the workload to deal with. Meanwhile, the project’s backlog is being based on the so-called features and user stories. WBS also features in Scrum, where it is not that different. As in Agile, so in Scrum, backlogs are the documents that are subject to constant tuning during the ongoing development process.
Dealing with the Units Measure
Having WBS at hand is an extremely important and beneficial thing, as it lets the engineers measure the efforts and time they are going to need to accomplish the project. Nonetheless, while we know that time is measured in seconds, weight in pounds, and so on and so forth, what are the measures of assessing the software development effort?
Well, there is an answer to this question, but it is an ambiguous one. Some teams prefer applying relative terms, such as function points, story points, etc. The others stick with rather practical units by estimating the software development effort in the man/hours/days, etc. correlation. Still, go talk to a business person who needs their software development, and start talking about the terms mentioned above. They’ll keep staring at you, knowing no limits to their bewilderment.
Therefore, keep the measure units down to earth. Whenever you are sitting at the negotiations table, talk solely about hours, weeks, months, etc., and the cost per hour for one unit of the team you’re about to compose. Keep it simple, and remember, everything you say can and will be used against you in the court of undelivered solutions!
3. Software Estimation: The Techniques
As you’ve already guessed, there are various project management methodologies and techniques that you can use while estimating a project. In general, they are broken down into the Traditional (applied to the waterfall approach) and Agile methodologies.
In his article “Software Estimation Using a Combination of Techniques” provides the following classification for these two most popular software estimation methods.
| Traditional | Agile |
| Analogy | Relative Sizing |
| Effort Method | Wideband Delphi |
| Programming Techniques | Planning Poker |
| Expert Judgement | Affinity Estimation |
| Delphi/Wideband Delphi | Ideal Time and Elapsed Time |
| Program Evaluation & Review | Disaggregation |
| CoCoMo 1/CoCoMo2 | Bottom-Up/Top-Down Estimation |
| Albrect’s Function Points | Constructive Agile Estimation Algorithm |
| Parametric Methods | Time, Budget, and Cost Estimation |
| Various Top-Down or Bottom-Up Techniques |
Yet, there is another look at this classification, provided by the IBM developerWorks knowledge library.
4. Handling Project Estimations: This Is How We Do It
Project estimation at HoneyComb takes place in accordance with a unique approach which we have crafted on the basis of mistakes and conclusions we made along the way of polishing our software development mastery. As a matter of fact, there are three major methods(components) we can apply when assessing an ordinary waterfall project.
- The analogy-based estimation reckons the effort required to deal with a current project on the basis of our previous projects’ similar requirements and features.
- Engaging the outside expert judgment is a must when the in-house team lacks the competency or requires input from aside.
- Harnessing the statistical data on our previous experiences in the field lets us forecast the outcome and the time & effort required for dealing with the project.
Whenever we embark upon a project, we are seeking to finalize the vision. We create a document that eventually becomes our project’s Work Breakdown Structure. We break the offered solution down into modules and sprints, making sure that our client gets a clear picture of how we are going to proceed with the tasks. Then, we analyze all the features in every module separately with the help of the statistical method, analogy-based estimation, and expert judgment.
At the end of the day, this is an elaborated document that features a detailed scheme of the work scope that we have to process within the framework of this particular project. The presence of the minimum and maximum values saves us from a widely distorted variability.
Having each and every feature estimated in a separate manner, we can provide our customers with a quote that gives a relatively realistic assessment of the effort needed.
Sure, this estimate cannot be considered a comprehensive one, as it still misses the estimates for the implementation of a whole scope of related activities, including UI/UX design, documentation writing, etc.
Now, when those results are added to the final quote, we can rest assured that we provide a realistic estimate.
There is a need to understand that SDLC envisages the completion of several tasks at the same time. For example, PM and QAs surely embark upon their duties simultaneously. Thus, we can all agree that providing the best “ballpark” estimate is the best we can do, as saying that we can count exactly how much time and effort we need would be unfair to our clients.
Product Engineering Approach
In his book Software Engineering Economics, Barry Boehm states: “Whatever the strengths of a software cost estimation technique, there is really no way we can expect the technique to compensate for our lack of definition or understanding of the software job to be done.”
Thus, using the product development model seems to be the most viable software effort estimation pattern of them all. Crafting software from scratch requires an enhanced level of dedication and flexibility. Furthermore, you should expect these two aspects to come in a long-term perspective. Therefore, one of the main advantages of the model is that it docks down the need for extensive investment in research. Experienced software engineers know that the very development process is extremely “spiky.” You have to be able to mitigate issues emerging out of nowhere, meaning preliminary effort estimates are not that important.
An orthodox SDLC envisages nothing else but a project-based collaboration heavily reliant on the waterfall approach. Yet, product engineering, which is a term presupposing an extended set of both tech and business activities, chiefly sticks with Agile. Therefore, instead of spending 30-40% percent of our time on planning, we handpick a dedicated team of professionals that are the most compatible with the needs of your clients. Then, we move from iteration to iteration, ensuring each of them is limited to a spring that lasts for 2-4 weeks. As a result, as the project progresses along the line of development, we can provide solid and predictable estimates regarding the date we are going to deploy it.
Our processes are Agile at their core, we prefer the Time & Material model, which lets us stay truthful with our customers. Instead of giving vapid promises at the very beginning of the project, we update our clients on and in the progress. There are three basic Agile software estimation techniques that we apply to get on with this task.
- Planning Poker. This is a game-like project effort estimation technique where each team member puts a card on the table that denotes their opinion on how long the iteration is going to take. This technique is good because it lets everyone voice their opinion and thus exterminates cognitive bias from the team.
- Ideal Time & Elapsed Time. Sometimes, tasks require more focus from the engineers, which is not the case with 8-hours working days. Letting them work 6 hours a day, extends the task completion to, for example, 4 days instead of the 3 planned, but it ensures the result deliverance.
- Relative Sizing Estimation. When using this model, a team takes a generic task, performs it, measures it, and then uses it as a measurement standard. The time/effort correlation recorded over the course of completing this task is applied as a measurement unit for completing the rest of iterations in the sprint.
However, here comes a bit of interesting statistical data to learn. As per the Standfish Group 2015 Chaos Report, roughly 3% of large waterfall projects turn out to be crowned with success. Meanwhile, the same-size Agile projects reach the 18% index of success. Meanwhile, if we’re talking about small projects estimated with the help of the waterfall approach, those are 44% of success that they enjoy. The difference is striking and, at the same time, informative of the efficiency of the product engineering approach.
Estimates? Are They Even Real?
Finally, the ultimate question you should ask yourself is, what is the customer value that all those estimates and Agile methodologies bring to you? In his bestselling book, #NoEstimates, Vasco Duarte states that folks are finding value in estimates only because they get the plans to comfort them and reduce their uncertainty. Yet, again, what is exactly the customer value here? That’s right! There is none!
Hence, it looks like the ability to predict the expenses required for your project in advance is not just a vital skill but also a great advantage to have. So, why don’t you try thinking about any estimate, assessment, evaluation, etc., as of an assumption – do not think that it must follow the same pattern every time you embark on it. Remember, everything is subject to change, and budgets and deadlines are not an exception to this rule. So, the only thing that must have the ultimate value for you is enjoying high-quality software, as, namely, quality, must remain stable, high, and unchangeable.
List of References
- Global Business Information Technology: An Integrated Systems Approach by Geoffrey Elliott – https://www.amazon.com/Global-Business-Information-Technology-integrated/dp/0321270126
- The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks, Jr. – https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959
- Applied Software Project Management by Andrew Stellman, Jennifer Greene – https://www.oreilly.com/library/view/applied-software-project/0596009488/
- Work Breakdown Structure (WBS) – https://www.workbreakdownstructure.com/
- Software Estimation Using a Combination of Techniques by Klaus Nielsen – https://books.google.com.ua/books/about/Software_Estimation_Using_a_Combination.html?id=JU1grgEACAAJ&redir_esc=y
- Is Your Project’s Best Estimation Method Agile or Conventional? – http://www.ibm.com/developerworks/library/d-estimation-agile-or-conventional-trs/index.html
- Software Engineering Economics by Barry W. Boehm – http://www.amazon.com/Software-Engineering-Economics-Barry-Boehm/dp/0138221227
- Standish Group 2015 Chaos Report – https://www.infoq.com/articles/standish-chaos-2015/
- No Estimate Book – http://noestimatesbook.com/