on September 20, 2023 -

Estimating your software project from scratch

Why estimation?

Estimation is the process which is applicable in every corner of personal and professional life. Estimation is one of the most important qualifying criteria which enables buyers (any individual or group-entity) to take an appropriate decision on buying the products-or-services from the respective seller.

During my career, I have seen many occasions when people were struggling in doing estimation for any software project. Many-a-times projects are underestimated and sellers of the products-or-services have to bear the losses. Buyers also apply the shrewd tactics in negotiations, sharing only abstract level information, creating pressure to submit the commercial urgently in a day or two and many other distracting & negotiating tactics. Under these circumstances this is quite obvious that the team from the seller side will not get much time for deep thinking and high-level thinking brings the opportunity to miss some of the normal or exceptional scenarios which will increase the project cost at the later stage.

#softwareprojectestimation #developmentcost #wbsbasedestimation #projectcommercial #softwarearchitecture #functionalarchitecture

Objective of the article

Whole objective of this article is simplified-learning, ready-to-use and almost-correct-estimation. In this article, my focus would be to explain estimation approach & template how one can apply the same in any relevant opportunity.

Software-project estimation template

One can refer the estimation template available on this link[Estimation-Model-Framework-Template]. Same template has been explained in this article as well.

Outcome of estimation-process

Usually from the estimation-process people think that the estimation talks about only cost-estimation, while the estimation process is beyond that.

Key outcome of estimation-process are

Effort estimation : which will explain how many person-days would be required to roll-out the software project.
Resource estimate : which will explain how many human-resources for the duration of estimated person-days would be required to roll-out the software project.
Cost estimation : which will explain the required monetary-expenses on human-resources to develop & deliver the software project as buyer’s expectation.
- Another point to note is that monetary-expenses are not just the labor-cost of software-development. There are other expenses which may-be tangible or intangible by virtue. Examples are physical-infrastructure cost (server, desktop, laptops, printers, scanners, memory, storage, other peripherals etc.), Other expense-fees are like software-license one-time-cost or recurring-cost, travel-expenses, accommodation-expenses, and many more.
- Bill-of-material (BoM) : BoM is the document which consolidates the list of all expense items. Expense-items listed in BoM documents are called bill-of-quantity (BoQ).
- Costing methodology for each BoQ may be common or specific to BoQ e.g. RedHat operating-system license fee is different from Windows server, RedHat Openshift cluster, Oracle weblogic, Oracle database, etc. all have different costing formulas.
- Costs for infrastructural BoQs are properly planned as per agreed milestones e.g. partial infrastructure can be requested to be available after 3 months before project-rollout, and remaining infrastructure can be requested with the gap of 4-4 months after project-rollout.

In order to keep the learning simple, the objective of this article I will keep the focus limited to development cost of software-project. Explanation of complete BoM can be taken later some other time as continuation of this article.

What is the WBS approach?

WBS i.e. work-breakdown-structure is the most natural way of doing cost-estimation for any software-project.

Before WBS, let’s understand the various project estimation techniques as follows

Bottom-up : break the entire big project into smaller functional-components, these functional-components are also called functional-application, domains or subdomains. Please refer to the diagram as given in section [Reference functional architecture].
Top-down : In this approach the deadline as per business needs comes first, the required team is allocated and then the project is executed to achieve the deadline.
Analogous : in this approach, project estimation is referred from a similar project which is already implemented.
Parametric : in this project also, project estimation is referred from a similar project and differences are parameterized to reach ro estimation of current project.
Three-point : in this approach, there are three outcomes that’s why this is called 3-point approach. 3 outcomes from 3-point technique are [the most optimistic, the most pessimistic and the most likely]. Stakeholders can sit together to review these 3 references and pick either of one or average-out of all three.
Expert judgment : in this approach, experts (individuals or groups or individuals) arrive at some estimation number, completely based on knowledge & experience.

Readers of this article would have seen many different situations in their career and any of the above different estimation techniques can be applied, but WBS is the base of all techniques. Most of the occasions, we all would have fallen in TOP-DOWN approach, in this article we would learn how the WBS will be used to calculate the project development cost.

Reference functional architecture

Other estimation approaches or models

Function point

Function Point Analysis was introduced by Allan J. Albrecht in 1979 at IBM, further International Function Point Users Group (IFPUG) maintains the FP standards

The Intention of this article is not to explain Function Point Analysis (FPA). This may be covered later some other time as a new or continuation of this article.

COCOMO model

COCOMO or Constructive Cost Estimation Model, which is based on line-of-code (LOC) to be written.

Static, Single Variable Models

In this model, one primary variable is identified as a key element for calculating the cost and effort.

Static, Multivariable Models

In this model, there is no single primary variable rather all variables are connected with each other, which participates in cost & effort calculation.

Let’s do estimation for your real software-project

Step-1 : Identify your project requirements

Requirement Id	Requirement Description
1	Requirement description 1
2	Requirement description 2
3	Requirement description 3
4	Requirement description 4
5	Requirement description 5
6	Requirement description 6
7	Requirement description 7
8	Requirement description 8
9	Requirement description 9
10	Requirement description 10
11	Requirement description 11
12	Requirement description 12
13	Requirement description 13
14	Requirement description 14
15	Requirement description 15
***	***
40	Requirement description 40
41	Requirement description 41
42	Requirement description 42
43	Requirement description 43
44	Requirement description 44
45	Requirement description 45
46	Requirement description 46
47	Requirement description 47
48	Requirement description 48
49	Requirement description 49
50	Requirement description 50

This will be exhaustive list of requirements which shall be shared by customer
Many reputed customers (tier-1 telecom operators, tier-1 bankers, etc.) share a detailed list of requirements with expectations of compliance status by software-vendor
Sometimes software-vendors do not get the exhaustive requirement list from the customer, in that case software-vendors should prepare the list themselves and get it aligned with the

**These are just sample requirements, you can rename the requirements and append more requirements as per your project need.customer.

Step-2 : Define your complexities & t-shirt size for efforts

Complexity Type Code	Complexity Type	Functional – PDs
L	Low	21
M	Medium	36
H	High	54
VH	Very High	78

Define t-shirt size of complexity for your requirements
One can add or remove or modify t-shirt sizes as per project need
Once your t-shirt size is aligned with all stakeholders, this needs to be mapped with each requirement.

Step-2(a) : Identify impacted layers from each project requirement

So far we learned the t-shirt size at each requirement level, while we all understand that each functional requirement will be implemented at various layers. Estimators can foresee the efforts due to impact on these layers, estimators can define their own t-shirt size of each layer. It is quite obvious that estimation done using t-shirt size of each layer will be more accurate than the requirement-level t-shirt size.

Complexity Type Code	Complexity Type	Backend – PD	Frontend – PD	DB – PD	Functional – PD
L	Low	9	9	3	21
M	Medium	15	15	6	36
H	High	24	24	6	54
VH	Very High	36	36	6	78

Common layers for requirement implementation

Frontend Layer
Backend Layer
Database Layer
Overall E2E impact (requirement-level)

** in order to keep things simplified, we shall consider only overall-complexity. The model can be granularized for each layer if required to be more accurate.

Step-3 : Assess & assign the complexity of each project requirement

Requirement Id	Requirement Description	Phases	Overall Complexity
1	Requirement description 1	Phase-1	High
2	Requirement description 2	Phase-1	Medium
3	Requirement description 3	Phase-1	Low
4	Requirement description 4	Phase-1	Very High
5	Requirement description 5	Phase-1	High
6	Requirement description 6	Phase-1	Medium
7	Requirement description 7	Phase-1	Low
8	Requirement description 8	Phase-1	Very High
9	Requirement description 9	Phase-1	High
10	Requirement description 10	Phase-2	Medium
11	Requirement description 11	Phase-1	Low
12	Requirement description 12	Phase-2	Very High
13	Requirement description 13	Phase-1	High
14	Requirement description 14	Phase-1	Medium
15	Requirement description 15	Phase-2	Low
***
40	Requirement description 40	Phase-1	Very High
41	Requirement description 41	Phase-1	High
42	Requirement description 42	Phase-1	Medium
43	Requirement description 43	Phase-1	Low
44	Requirement description 44	Phase-1	Very High
45	Requirement description 45	Phase-2	High
46	Requirement description 46	Phase-1	High
47	Requirement description 47	Phase-1	High
48	Requirement description 48	Phase-1	High
49	Requirement description 49	Phase-1	High
50	Requirement description 50	Phase-2	High

**T-shirt size mapping with each requirement is random, you can change complexity t-shirt size as per your assessment at ground.

Step-3(a) : Granular complexity mapping for each project requirement

Requirement Id	Requirement Description	Phases	Overall Complexity	Frontend Complexity	Backend Complexity	Database Complexity
1	Requirement description 1	Phase-1	High	High	High	High
2	Requirement description 2	Phase-1	Medium	Medium	Medium	Medium
3	Requirement description 3	Phase-1	Low	Low	Low	Low
4	Requirement description 4	Phase-1	Very High	Very High	Very High	Very High
5	Requirement description 5	Phase-1	High	High	High	High
6	Requirement description 6	Phase-1	Medium	Medium	Medium	Medium
7	Requirement description 7	Phase-1	Low	Low	Low	Low
8	Requirement description 8	Phase-1	Very High	Very High	Very High	Very High
9	Requirement description 9	Phase-1	High	High	High	High
10	Requirement description 10	Phase-2	Medium	Medium	Medium	Medium
11	Requirement description 11	Phase-1	Low	Low	Low	Low
12	Requirement description 12	Phase-2	Very High	Very High	Very High	Very High
13	Requirement description 13	Phase-1	High	High	High	High
14	Requirement description 14	Phase-1	Medium	Medium	Medium	Medium
15	Requirement description 15	Phase-2	Low	Low	Low	Low
***
45	Requirement description 45	Phase-2	High	High	High	High
46	Requirement description 46	Phase-1	High	High	High	High
47	Requirement description 47	Phase-1	High	High	High	High
48	Requirement description 48	Phase-1	High	High	High	High
49	Requirement description 49	Phase-1	High	High	High	High
50	Requirement description 50	Phase-2	High	High	High	High

** One can continue with granular complexity mapping if there is a need to discover more closure estimation and sufficient time is available to do this exercise.

** In order to keep things simplified, we shall consider only overall-complexity. The model can be granularized for each layer if required to be more accurate.

Step-4 : Have a look on project requirements complexity summary

Overall Complexity	Phases
Overall Complexity	Phase-1	Phase-2	Grand Total
Low	8	3	11
Medium	10	1	11
High	13	4	17
Very High	9	2	11
Grand Total	40	10	50

** Number of requirements should be almost properly distributed among complexities.

** This table has sample data, in real life requirements distribution among complexities will vary.

Since in this article, we consider overall-complexity instead of taking granular-layered-complexity, the following would be the requirement summary from the above table.

Requirement quantitative summary
Complexity level	Count of requirements
Low	11
Medium	11
High	17
Very High	11
Total	50

Step-5 : Get complexity wise development effort

Complexity wise development effort summary
Complexity level	Unit level efforts (PD)	Count of requirements	Total DEV effort (PDs)
Low	21	11	231
Medium	36	11	396
High	54	17	918
Very High	78	11	858
	Total	50	2403

** PD = person day

In the above table, the last column shows total functional development effort which is the outcome of (requirement count x t-shirt size).

Step-6 : Consider additional development efforts of non-functional components

Overall Coding Breakup
Breakup item	Total coding effort
Development & unit test of functional components	2403
Development & unit test of non-functional-component or library e.g. Authentication & Authorization, Logging & Monitoring, Activity-log, etc.	481
Total	2884

In the above table one can check that the first & second row are actual coding efforts of function & non-functional components or requirements. Development effort for functional components is the same as mentioned in the previous section.

Step-7 : Get ready to arrive on overall project effort for corresponding SDLC phases of your project

Overall project effort for corresponding SDLC phases
SDLC Phases	Efforts in PDs	Standard % allocation	Remark & Outcome
Requirement discussion + Business Information gathering	1081	15%	Business requirement specification document, customer journeys, business object hierarchy, etc.
System design and analysis	1081	15%	Functional architecture, System architecture, HLD, Sequence Flow, etc
Total development effort	2884	40%	Coding & Unit test
System integration test (SIT)	1442	20%	System/functional integration test (SIT by QA team)
Final user testing (FUT / UAT)	721	10%	User acceptance test (by customer business team or IT team with support of QA team)
Total effort (A)	7209

For the readers who have not done estimation before, small organization, startup entity, they usually lack standard processes and consider only software-coding effort project-costing and add some factor for margin.

This table is very useful for those kind of readers, they need to understand that overall-project-effort should also consider for effort burnt during requirement discussion, analysis & assessment of requirement, project management, coordination with multiple stakeholders, aligning decisions with stakeholder, preparing various kinds of documents, writing unit-test, performing functional-test, get user-acceptance through UAT and so on.

Step-8 : Consider additional non-development efforts in overall project efforts on top of regular SDLC components (extension)

Overall project efforts including additional non-development efforts on top of regular SDLC components (extension)
Additional non-DEV effort	PDs	Remark
Performance engineering and execution	264	Performance engineering is not continuous work, once production-deployable code is ready , performance engineering & execution can be performed. This is very special work and requires niche expertise, so a dedicated team having PT expertises and size could be as per your project criticality and resource capability.Consider 1 year of total project duration, 4 months could be duration of performance-engineering, 1 x performance lead & 2 x performance SME can be considered.
Security and vulnerability scan and fixes	198	Security scan is very special work and requires a niche skill set. Focused team having security expertises would be required sometime mid of project till end of project.1 x security lead / SME can for 3/4 duration of the project
Infrastructure readiness of each environment (Production and non-production)	50	Effort for this component will depend on environment strategy agreed. If we go with standard environment strategy there will be a need of Development environment (DIT), Functional test environment (SIT by QA team), User acceptance test environment (UAT), Preprod environment (Load test by PT team), Production environment.(i.e. 5 environments => DIT + SIT + UAT + Preprod + Production)
Software tools setup on each environment	120	Example Apache Tomcat, Apache Web Server, Analytics tools, etc. X number of tools requiring Y PDs for each tool can be considered and the same effort will be replicated for each environment.
Database setup		High availability mode of database for each environment
CI/CD environment & pipeline setup		CI/CD Pipeline to be setup for each repository by DevOps lead.
UX activities	132	1 SME can be considered for experience design & user interface design for 50% for project duration.
Performing data migration & cutover activities	150	The Brownfield project will have legacy databases and channels, which will be required for a new system or platform. Data-migration is again to be performed by a dedicated team. Solution approach & migration utility would be written, multiple dry-runs would be performed, migration onto production might be performed in multiple drops. Let’s assume there is X number of dry runs and Y number of drops of migration for final cutover.Not applicable for greenfield projects.
Total effort (B)	914
Overall effort (A + B)	8123
Overall effort (A + B) after 75% efficiency	10154

Just like we considered efforts for other SDLC phases in overall project efforts, same way there are some additional non-development activities which are burnt during the project-execution.

These activities are completely project dependent, if your project does not require performance engineering, security scan and likewise other non-development activities, one can ignore these activities from the effort calculation approach.

In the last row, one will notice that 75% efficient-factor is considered i.e. 25% efforts are expected to be burnt in non-productive works like discussion, meeting, follow-up and so on. Hene 75% efficient-factor is considered on top of overall development + non-development efforts. Again this factor will depend completely on your effort calculation approach & negotiation strategies.

Step-9 : Get the overall project costing for proposal

Overall project cost
Item Name	Value
Product duration in months	462
Average team size	40
Project duration in months	12
Average resource salary (Lakh per annum in INR)	25
Project cost = team size * average salary (LPA) for total project duration	962
Total project cost in INR (tax excluded) =	962

This is a table whose outcome everybody is interested in including customer and vendor’s management. This is the table which becomes the part of the actual proposal except the information regarding average salary of resources.

Let’s understand how this table is prepared

[Product duration in months], one will get this number from [Overall effort (A + B) after 75% efficiency], divide this number by [number of working days in a month]. Number of days could be any of 21 or 22, or use this number as per your negotiation strategy.
[Average team size], this number one will arrive based on experience and expected resource loading. For the sake of explanation, [Average team size = 40] is considered
[Project duration in months] = [Product duration in months]/[Average team size]
[Average resource salary (Lakh per annum in INR)], one will consider this number based on working location and country standard or resource availability.
Finally the [Total project cost in INR (tax excluded)] is [team size] x [average salary (LPA)]

Step-10 : Plan your roles and prepare the resource loading as per roles required for the complete project implementation

Resource Loading Summary
Role name	Experience in number of years	Skill required & Job description	Engagement duration in the project	Is sharable resource with other projects	% allocation in project (if sharable)	Remark
Project manager
Enterprise architect
Solution architect
Cloud architect
Business analyst
Technology leads
Frontend developers
Backend developers
QA group (Lead & experts)
Performance group (Lead & experts)
Security group (Lead & experts)
Data migration & cutover group (Lead & experts)
User experience & interface designer

** Template for resource-loading.

Roles mentioned in the above table are more-less standard roles, one would need in any software-project development. One can customize as per project need and effort-estimation & cost-estimation arrived in earlier sections.

One can define the resource profile as per the project expectation, budget, criticality, value-add from the experience, let me share some situations which might help you to find the right resource

Enterprise architecture (EA) can play an important role if application-or-platform is large-complex-long (LCL), EA will provide the architecture-vision and approach to achieve the architecture-vision. EA will define the foundation-architecture and related artifacts as explained in earlier article Whitepaper : Software-architecture-as-code (SAaC) and will ensure any modification to these master architecture artifacts. So having this idea in mind, one can plan a dedicated or shareable EA and if shared then what % of allocation should be beneficial for the project.
Cloud architect (CA), this role would be required only when the cloud is going to be the deployment platform of your project. CA will define the cloud-strategy and prepare the artifacts related to cloud-infrastructure-setup, scripts for infrastructure-as-code, automated scripts for CI/CD pipeline creation for applicable repositories and so on. Once the IaC scripts are ready for all the entire cloud-infrastructure, applicable architecture-building-blocks (ABB), CI/CD pipeline for all functional repositories, utilization/allocation of CA can be lower down for simple & medium projects, but for LCL kind of projects there should be a dedicated CA and may-be a team of CAs would be required.
Security Architect (Sec-A), this role will be to define the security guideline and may-be one can seek advice from EA. Sec-A will perform security vulnerability-scan on expected major software-releases and will make the development-team understand the vulnerability-scan report along with the expected approach to mitigate the vulnerability. Engagement of Sec-A will start a few weeks-or-months earlier than the first major release of a software-project into the QA or UAT environment, so that before deployment into the production environment all security-risks have been fixed or mitigated. Post deployment of the first major release, in agile there will be continuous sprint delivery, there can be automated scripts which can run along with CI/CD pipeline to produce the vulnerability-reports, these scripts will require changes based on changes in EP-URLs or new integration or new ABB introduced. Utilization/allocation of Sec-As can be lower down for simple & medium projects, but for LCL kind of projects there should be a dedicated Sec-A and may-be a team of Sec-As would be required.
Performance Architect (PA), similar principle like Sec-A is applied for the engagement of PA. Based on the reports produced by PA, changes in architecture or functional optimization can be performed.
So far the above explanation gives a fair idea about each role. One should think about each role considered in the project’s team based on importance, expectation from the role and probable contribution to the project. One can apply this criteria while building the overall project team.

Important reference links

About author

Profile : Rajesh Verma – Brief profile

Source : link for this article here

Series : S1 (Architecture & design)

Episode : S1E3 (Estimating your software project from scratch)

Author’s approach : Rajesh wants to share his learning & experience gained throughout his career from various sources. Author started the series on architectural topics and this article is the first episode in that attempt. Author feels that lots of information is available on various forums, but scattered here & there. Episodes in this series will be designed for most of the relevant topics in architecture-&-design, published gradually and organized in logical sequence. Principally episodes will have linkage with other episodes, so that readers can have proper connection among the topics and would be able to correlate with ongoing activities in their software life. Topics for example will be related to functional architecture, integration architecture, deployment architecture, microscopic view of mostly architecture-building-blocks (ABBs), security guidelines & approach to comply, performance KPIs & engineering, git branch & DevOps enabled automation strategy, NFR aspects (e.g. scalability, high-availability, stability, resiliency, etc.), commonly used architecture styles & design patterns, cloudification approaches, multi-tenancy approach, data migration, channel-cutover & rollout strategy, process standardization & simplification, greenfield rollout & brownfield transformation journeys, etc.

Thank you for reading the post, please stay connected.

No Tag

Whitepaper : Estimating your software project from scratch