01 Oct

Project Estimations

Project Estimations


“ The best we can do is size up the chances, calculate the risks involved,
estimate our ability to deal with them, and then make our plans with confidence.” 

~ Henry Ford

This article is a precious part of the hybris Project Patterns series.

In short: to estimate means to make an educated guess.

For example, if someone would ask you how much is the half of 1817, you would quickly round it down to 1800 and half that, which is much easier. Since half is 900, you would estimate that the answer would be around 900. How did we make this estimation and what gives us the confidence that our estimation is credible enough? 

It is a fact that estimations are based on certain knowledge of the matter and a large portion of experience. Knowledge and experience are giving us enough confidence that the estimation is conveniently close to the real answer. 

So, why can’t we calculate the exact answer?

We could, but it would either take a bit more time, like a couple of instants in the case above, or much more time, in the case of calculating a complex software project. In both cases, until we complete the calculation, we cannot be certain of the answer. Moreover, until we actually do the math we cannot say exactly how much effort it took us. The same is with a software project – until we deliver the very last bit of the new solution, we cannot say with certainty how much effort that has cost us and what the associated budget has been.

Therefore, while doing a simple division calculus is a matter of seconds, “calculating” a complete software project may take weeks to evaluate. For that we do estimations: or guessing – with a good level of confidence – the total cost of a project before it starts.

Even thought there are several respectable books about various estimations techniques, estimations are still considered as a “dark art“ in software development. Most readings discuss WHY and HOW we estimate. This article focuses on WHAT we estimate. It emphasizes the important elements of project evaluations and offers a blueprint, which can help you make your own estimations.


Often initial estimations are done in a hurry, without sufficient grasp of requirements and business domains. Respectively, the initial estimations are literally thrown in the bin and replaced by new ones after the start of the project. Estimations made during the project tend to overlook requirements and key tasks, which are not explicitly stated, but are assumed by the Client. This makes the whole estimation unrealistic and dangerous, affecting time, budgets and … business relationships.


Consider carefully all project activities that require efforts. Do not exclude any of them, even if negligible. List them in a template, so that you build a checklist, which you can use in each project. Further, specialize the template to address specifics of different business domains. 

Related patterns

ClientOverall Consulting, hybris Functional Consultant, Workshop, Domain Methodology, Software Methodology, Glossary, Requirements Gathering, Platform Expectations, System Actor Inventory, Pages Inventory, Integration Points Inventory, Internationalization, UED Planning, Communication, Business User Enablement 


What do we Estimate?

Here we are: at the verge of a starting new project. The Business Client offers a list of requirements and expects a proposal for the realization’s budget.

To provide an indication of a budget requires us to evaluate the requirements and estimate the effort they entail. After estimating the total production effort we attach a price tag to it, and get a picture of the financial budget.

With a certain confidence we can say that the total production effort is highly influenced by the amount, complexity and diversity of the Requirements. Hence, we could sketch a preliminary estimation graph like the one below:



It would be right to expect that the efforts, behind each requirement, involve analysis, implementation and thorough testing of the same.

As a start, we separate the concept “estimation effort” from the “budget”, which is associated with it: the estimation represents the complete workload needed to produce a software product, while the budget indicates the monetary equivalent for acquiring that product.

The subject here is about estimation completeness. Budget calculations depend largely on the price model your company adopts when formulating the final cost indication.


Estimating Requirements

Let’s begin our exploration by boiling Requirements down to their most basic ingredients. In software projects, Requirements are often qualified as Functional or Non-Functional, where the functional ones cover the behavior of the system, and the non-functional represent various restrictions like usability, accessibility, performance, security, legal rules, tax regulations, corporate guidelines, etc.

A gentle warning: Business people don’t think in “functional and non-functional” requirements. They think about needs, goals, user-experiences, KPIs and alike. Hence, in most of the cases, the requirements that you get are in the form of a wish list or pure prose. Like so, it is your task to bridge the Business’ mental world with finer structured requirements in order to offer, for each feature, estimations with a decent level of confidence.

It is your role to think along with the Business and explain what their requirement really means in terms of development, integration, front-end design and usability. And remember also to talk about benefits, risks and pitfalls of each approach.


The requirements represent the major workload for a development team. And even if a platform, like hybris, offers a good level of the desired features, there is always a need to alter their behavior or develop new functionality. As we implement Business requirements we spend efforts in configuring the existing platform capabilities and in developing customized modules

Furthermore, when the new solution becomes a part of a larger software ecosystem, the realization of requirements demands the construction of certain application interfaces between the solution and the existing systems. Depending on the complexity and diversity of the system interfaces, the overall integration effort may vary drastically from one project to another, thus influencing the effort calculation. In this case, what comes handy is creating an inventory of Integration Points, which clearly identifies all interactions between the systems.

Modern projects, offering omni-channel user experiences, often involve intensive human interaction. There, a good amount of attention is paid in creating suitable User Interfaces (UI) for end-consumers, business workers, partners and corporate users.

Summarizing the multiple elements of the requirements enriches the estimation graph, like:




Ingredients of Total Project Effort

Undoubtedly, starting with the Requirements is merely an initial step towards calculating the total cost of a project. The goal of doing estimations is to evaluate every project dimension and come up with a picture of the total effort.

To provide estimations of a final budget we look also at all other project facets responsible for delivering an all-inclusive solution. Those could be team organization, system configuration, acceptance activities, maintenance support, user enablement, transition processes, etc. What we actually do is estimating the entire effort involved in accomplishing the software project.

In addition to the realization of all Business Requirements, the total project effort usually includes also:

  • Installation and configuration of the selected e-commerce platform,
  • User Experience Design (UED) and the related Artwork,
  • Quality Assurance (QA) and Acceptance activities,
  • Go-Live activities and Change Management workload,
  • Setup of a project structure

We can portray the collaboration of those ingredients in the following estimation graph:




Let us glance over the new aspects and explain their significance:

Platform Setup refers to important tasks related to the installation of the e-commerce platform on the designated hardware. The efforts associated with those tasks should be added to the overall calculation, because they can be substantial. Here, considerations should be given also to the initial configuration of software modules related to the core functionality of the platform – for example, structuring and setup up of product catalogs, users, search engine, assets storage, etc. Installing the hardware with its own supporting software represents also a tangible project deliverable with a corresponding workload.

Most of the e-commerce programs address complex User Experiences (UX), which intertwine in a blend of processes, page flows and user interactions. Depending on the channels and touch-points required by the solution, the User Experience Design (UED) and its accompanying artwork affect the development efforts. UED provides all the artifacts, which are required for human interaction with the system. Usually, those artifacts are in the form of page designs and flows, functional maps, sketches, wireframes, clickable prototypes and so on. The UED provides the primary building components of the aforementioned User Interface creation.

The estimation of one single feature requires not only calculating its realization, but also evaluating its management, display and usage. In my practice I use two highly valuable UED artifacts, which support the estimations: the Page Inventory and the Actor Inventory.

In essence, the Page Inventory is a project deliverable, which captures information about all visual elements that are used for communication with a user – pages, dialogs, wizards, emails, messages and notifications; over every interactive channel – web, mobile, back-office UI, promotional banner, newspaper campaign, etc.

The Actor Inventory artifact focuses on all actors interacting with the system – from online visitors and B2B buyers, to business users like content managers, customer service agents, copywriters, marketers and administrators. This document employs persona- and use case analysis to discover possible users of the system, their responsibilities and associated chores.

Both artifacts contribute significantly to the estimation process, as they allow the team to disclose key characteristics of the solution related to its usage, business processes and the involved actors.


A project success would be unthinkable without decent Quality Assurance (QA) and Acceptance activities. Various levels of testing and validations allow both sides – the Client and the Implementation Partner – to do their best in guaranteeing the stability and quality of the solution. When estimating those activities do not forget to include all efforts related to them, like:

  • Creation of a Test Plan and installation of Test tools
  • Creation and execution of functional- and non-functional tests
  • Creation and execution of end-to-end tests and User Experience interviews
  • Realization of test automation, performance and integration solidness
  • Support of various User Acceptance Test (UAT) phases for each major system launch

In their book Agile Testing”, the authors Lisa Crispin and Janet Gregory advocate using Testing Quadrants to identify the type of tests, which would be addressed for constructing the solution.

Similarly, for the sake of estimations, think about the various tests you consider important to be accomplished. Include these in your estimation. Even thought testing activities augment the overall budget, they are not negligible due to their significance. Experience shows that, at the end, the Client highly appreciates the fact that you put Testing in a spotlight and plan to take it seriously.


The Go Live and Change Management topics embody the whole spectrum of activities related to launching the solution, like international rollouts, business user enablement and corresponding Change Management tasks. The magnitude of those activities depends largely on the business model of the Client and are affected by corporate structures, organization and process maturity, culture, customer ecosystem, office locations and so on.

Here is a short checklist of topics to reflect on for Go Live activities:

  • Preparation and realization of code deployment on production environments
  • Establishment of back-up and restore processes
  • Introduction of monitoring procedures
  • Creation and execution of an International Roll-out plan
  • Production of localized content and introducing it to the system
  • Preparation of documentation – technical and functional 
  • Production and execution of User trainings
  • Support the Client in their internal communication plans
  • Support the Client in hiring personnel for new roles required by the project
  • Support the Client in building technical knowledge of the platform
  • Define and execute cut-over procedures in case of re-platforming
  • Agreement and setup of a dedicated Service Level Agreement (SLA)

… and so on. 

Pay special attention to those topics since they might be smaller or bigger projects on their own! For example, in a multinational setup, producing localized product- and editorial content would require the involvement of various people, strict planning, intensive communication, rigorous validation and … an immense amount of coordination. In practice, the content creation is often defined as a parallel project in the overall corporate program.


Finally, add to your estimations the efforts related to the Project Setup. Take into account the workload, which is needed to ensure smooth project run. The project roles associated with this activity are not directly related to requirements or infrastructure, but rather to the overall delivery process and its wellbeing. Accordingly, consider complementing the calculation with the effort behind Project- and Account Management, Agile coaching, External Consulting, and alike.

What Else should we Consider for Estimation? 

A project might involve other supporting activities, which supplement the total effort. For example, embarking on a project might require learning new concepts, doing research and following specialized trainings. These help reducing risks, related to uncertainty of complex functionality and new technologies. You can name them as a Development Margin and estimate the corresponding efforts, as part of the overall effort.

Moreover, experience teaches us that many large projects start with an initial Discovery phase in order to study the feasibility of the overall project. Starting from the same list of requirements the team would be able to get a grip on the future architecture, identify risks, and even re-evaluate the project goals.

Such short Discovery phases are sparkled with discussions about the fundamental business requirements and their value. In parallel, a fit-gap analysis would be done to indicate which features are supported by the selected solution platform and to what extend. The team might also propose to implement a short proof-of-concepts (POC) or conduct a targeted user-experience test (UxT) to reach enhanced comprehension of the project complexity. Those activities are also considered as an effort, therefore can be estimated and accounted for.

Having in mind the supporting activities, the new estimation diagram would look like:




In a recent engagement with a Client it has been decided to start with an elaborated POC phase. The goals were to study the complexity of the requirements, outline solutions to major performance challenges and estimate a budget for the future international roll-out targeting 60+ countries. This was a sort of study where the results were unpredictable, and therefore the estimations could wildly vary. Through a series of Workshops the POC evolved into a representative report, which allowed the Client to preview possible scenarios with their pros and cons. Each scenario resulted in a potential solution with own approach, timeline and cost. The POC had its own estimation of efforts and budget, which was given prior to the start of the POC phase.


Who does the Estimations?

You would not find in a software company a dedicated role like “Estimation Consultant”. Estimations should be done by the Team who potentially would do the realization of the future project: the Team has all the knowledge about how to estimate the complete workload and knows also how much it would take for the same Team to do the job. 

Think also about the fact that different teams can complete the same work with different speed, different means and possibly different approaches. Thus, in case you need to do estimations for another team, make sure you take some average numbers, based on previous project experience and seniority of the team members. Here, having a predefined estimation template at hand helps a lot! Read further on to learn how …


When to do Estimations?

The Team faces evaluation of business requirements as early as during the Request for Proposal (RFP) phase – before the project starts. This is the moment when the Requirements are not detailed enough and the uncertainty is high.

In the Constructions phase of the project, Requirements would be evaluated again to come to more predictable estimation of efforts and planning. A common habit in agile projects is to estimate each unit of work, known as a User Story, and this way enter the planning of the upcoming development cycle. Estimations done just before the implementation are more accurate than the initial estimations, because – at that moment – the requirement is clearer and all its aspects have been considered in greater details.

Ideally, the fine-tuned estimations should fit within the initial estimations. In reality, this is hard due to initial fuzziness of the requirements and the “lot of unknowns” at the start of the project. This is why mastering the estimation process is a long challenging voyage, but – at the end – results in credible and highly useful artifacts.

Blueprint your Project Estimations

Let us reiterate: How do we do estimations?

“Well, we get the list of requirements; next, we take into consideration all important and supporting activities, and then we start estimating … to the best of our knowledge, of course.“

Since we base our estimations on the initial input of requirements, there is always a risk that we might be missing something substantial – some requirements might not be explicitly listed or are simply “assumed” by those creating the requirements list. 

As a rule of thumb, each required feature should be evaluated by all its aspects, namely:

  • Data model and behavior
  • Application interfaces
  • Management of the feature
  • Usage by various users (i.e. user interfaces and touch-points)

Frequently, the requestors do not think about all aspects that would require effort. It is your role to ensure that.


The key question you could ask is:

“How do we know we are complete in our estimations? How can we ensure we account for all important facets of the project, even those not mentioned by the Client … but still require attention or efforts?”

Overlooking things is the biggest cause of inaccurate estimates. Our estimates would not provide for anything that has been ignored and forgotten. So, how about we turn the things around: instead of doing estimations based on input, we prepare in advance an estimation template, which can be used in most of the cases.

A blueprint, like the one below, would employ strong domain methodology and provide a good coverage of requirements and activities, which are suitable for most projects. 




Having a template gives you a structure and serves as a checklist to remind you about all that is normally required for such class of a project.

You can use a general all-round template to set the basics for all projects.

However, you can also go a step further and use domain-oriented estimation templates to address the specifics in domains like B2B, B2C, PIM, e-Procurement, Printing, Multi-channel, etc. Those specialized templates – especially when well documented – offer much more granularity and specialization because they match far better the Clients’ domains and offer the so-desired completeness we are aiming for.





Provided that you start with a template, you could plot the Client’s requirements onto this blueprint with ease and initiate from there your estimation workout. Estimations done in such fashion rely on your proven Domain know-how that your team masters and allows you to speed up your estimations process.

Building estimation templates requires time and can be considered as an “upfront investment”. However, this approach comes with its invaluable merits: it allows you to build knowledge between projects and to create average indicators about your common workload. This technique, known as Analogous Estimation, can help you in evaluating similar projects by comparing them. The opportunities of using templates are significant and your team will start cherish them soon after you apply the templates a couple of times.

Bottom line: instead of using the incoming requirements to create an estimation list, use an estimation template and map the requirements to it in an organized and guided manner.


Your Preliminary Backlog

Thinking beyond the estimation “exercise” helps us realize that estimations should not only be perceived as an input for a pre-sales pitch. One of the prime values of having a structured estimation template is that it becomes your initial project backlog of things to do. 

In our projects the transition from estimations to a backlog is almost immediate: the estimation template “is” already a primary backlog. This way we never lose the link between what we have estimated and what needs to be done in reality. The connection with the initial requirements becomes inherent and we can always measure – with confidence – the coverage of the original needs by our working artifacts, like user stories, test cases, page designs, architectural patterns, and so on. We never throw out the initial estimations, because they serve as a backbone of the overall project approach and planning.

The next step is to blend into the regular agile process, namely, to start with the prioritization of all the elements and the planning. 


When you go over several project estimations, learn from your own experience: accumulate all estimations and study them. Use average estimations to see how much the new project differs from your overall estimation. In time you will get better in doing estimations and capitalize from your knowledge.

The ultimate maturity level would be achieved when you manage to create a template of most common features and activities, and create an estimation blueprint for the business domains you specialize in. Answering the question WHAT needs to be estimated defines the complete scope of the project. After listing all that requires estimation apply your favorite estimation technique to produce the total effort and its related cost.


  Continue reading:


~  Did you like this article? Please let us know ...  


Total votes: 0