How to estimate software projects. Chapter 1: necessary inputs
Next chapters:
One of the biggest pain in Software Project Management are estimations. In every company I worked for there was a need to somehow understand how much time and money for the implementation of a business feature is required. And no wonder why: the business tries to maximize the ROI from the feature development; that way we can pick a feature that will bring more money while requiring less effort. Also, the development does not happen in vacuum; say marketing campaigns should be scheduled in advanced.
From the perspective of a service company, the estimations are frequently required during the process called RFP - request for proposal, also known as RFQ - request for quota. Having some brief description the company should reply with a proposal including time and money budgets to create a piece of software.
Estimating software development is hard; however I believe it is a skill one can improve over time. In this series I would like to show the methodology I use for estimations. It will have at least 3 parts:
- Necessary Inputs
- Solution Design and Comparison
- Calculating budget and timeline
The estimations can be done with different level of certainty which depends on the level of details you get; the approach I use allow to do both ballpark estimations and more precise ones.
At the end of the series I will provide an excel template for software estimations.
Today, we will discuss the inputs required to start estimating whatever you will be implementing in future.
Requirements
First of all you would like to understand what your customer is willing to achieve. You should look at it from the business perspective, not from a technical one. How this feature will benefit the end user? How the new system is going to generate value? Does it worth creating the system in the first place?
Example: A customer comes to you and asks to create a blogging engine for their corporate blog. You reply: 'no problem' and roll out a check for couple of hundreds thousands dollars. The customer gets frustrated and abandons any communication. Apparently, they didn't need anything special and any platform like WordPress or Ghost would work just fine.
But ok, the custom software is required all the time. When you understand the value proposition, it's time to dive a bit deeper and understand the system on the high level. Here we come to functional requirements.
Functional Requirements
Functional requirements are what the system should do in order to bring value to the user. Successful estimation really depend on how well you can specify the areas of functionality you would like to implement. I like to work with them in terms of User Scenarios.
Typically, architects do not create those scenarios: we expect them to be ready from the product owners and UX designers. Having them help to understand the personas the system will interact with, their needs and objectives. This will be especially helpful when building context diagrams.
It is important to know that the world mostly work in an Agile way, which is actually great. You won't have a thousand page technical specification. You won't have super detailed User Stories from the get go, but it's fine. At this stage you need a high level understanding of user journeys.
Example: the user can login into a mobile bank with login and password(story 1). The user can see the list of the accounts(story 2). The user can see the list of transactions for the period of time(story 3). The user can make a money transfer to the user of the same bank by the phone number(story 4).
Frequently, you will not get any user stories at all. There will be just a high level specification of the system like in Architecture Kata. Your job will be to extract the desired functionality by yourself.
Non-functional requirements
Those requirements describe not what the system should do, rather how it should do it. How fast? How many users should be supported? What security standards should be applied?
The trick with NFRs is that customers rarely think about them. They might have an idea about the amount of users they would like to target. They also understand the system in design should work relatively fast. However there are a lot of NFRs which will affect the target architecture and therefore the estimation. Your job is to find out the most critical ones even if the high level estimation is required.
Part of those requirements will explicitly reside right in the initial request, i.e. a target number of users. Others will come from the domain knowledge. Your job is to extract those requirements and prioritize them. I like how this process is covered in "Fundamentals of Software Architecture". I will be publishing a book review for it soon enough :)
Constraints
Aside from functional and non-functional requirements there are constraints. These requirements neither the architect, nor the customer can change. For example, the customer notes that the company deploys all their products to an Azure Cloud and they are not ready to negotiate going multicloud. On the other side constraints may come from the outside of the company, i.e. laws. You all heard about GDPR, CCPA and other restrictions and acts. If you do not obey those, you will face enormous fines, and the majority of the companies are trying to abide. Long story short, you need to fulfill those requirements no matter what, so they are called constraints.
Answers
Typically you will have a couple of dozens questions after reading the initial request. It is worth to ask for at least 1 hour Q&A session to ask them and understand better the request. This technique proved to help avoiding the conceptual misunderstanding and align the product vision.
Personas and systems
Despite the fact you should be able to create the list of personas from Functional Requirements, you may find useful to maintain a list of people with different roles who interact with your system.
Example: you design a system with some user generated content. It is tempting to say that we have only 1 user of the system - content creator. However, if you ask yourself should anybody access the system as well, you will find out you would prefer to have a role of a support person to help with technical issues or account management. And here you discovered a whole new area of requirements.
Aside from the persons chances are your system is going to interact with external systems. It is really easy to come up with examples: social network logins, sending emails, storing analytics and so on. Those integrations may drive further requirements like security, interoperability and so on. This is why it is important to map those system at the beginning.
Assumptions
The list of requirements will be not complete. Never. Accept it. Some requirements you will not be able to gather, some of them customer will not be thinking of for now. Sometimes there will be no opportunity to ask a proper question(believe me, I saw it happened many times).
Assumptions come to help. You will be doing them implicitly anyway, so writing them down explicitly helps to communicate the solution and estimation inside your group and to the customer.
If you're doing the estimations in a spreadsheet processor like Excel or Google Sheets, it's worth having a separate tab with assumptions grouped by areas.
Example: for a mobile application estimation I have the groups of assumptions on the supported OS versions, technologies used(crossplatform or native), backend integration(REST or GraphQL or Websockets), documentation provided, people, available for the communication and so on.
The estimations become extremely valuable right after signing the contract(or starting feature development). You will be on the safe side, as when the assumption proves itself wrong, you will have it documented: both parties took the risk, and now will work together to resolve the issue instead of blaming each other.
Estimation Timeline & Output Format
You can spend on estimations couple of days. You may also spend a whole month for it. But if you spend a month, and the estimation was required two days after the request, you wasted your time and achieved nothing. It is highly important to know when the result is expected and what format will be convenient.
Different customers expect different things. Some companies will ask you to provide a detailed work breakdown, granular estimations and a resource plan. Some will ask only for the budget and a timeline. Save your time: ask about the output in advance.
Estimation Team
The last but not least. Despite I believe in my audience, nobody can know everything. You will require a team of people who can help building a proper estimation. Let's see who they are.
Platform Experts
You system is likely to include some web apps, backend services, mobile apps and so on. Don't try to estimate everything on your own: bring the specialists. Delegate.
Fellow Architects
The architects do also have their specialties as well. System architects, Data Architects are examples coming to my mind. You might want to ask their advise as well. Also, having another couple of eyes reviewing your system design always help to check if anything is missed. In EPAM Systems it is mandatory practices: there is always an overseeing architect for a solution under design.
Subject Matter Experts
RFPs come from different companies. And even if you're estimating a new piece of software for your employer you might be a new person in the domain. As we figured out earlier, the domain is a significant source of requirements, so better to bring people who are proficient in the domain. We call them subject matter experts.
Presale Manager
For the service companies it is important to present the estimation result in a nicely formatted way, that is expected by the customer. Although solution architects are typically good presenters, it is useful to have a person who can pack up the results of estimation team and present them properly.
Summary
Good! You have requirements gathered, came up with a list of assumptions and set up your team, you can proceed to the next step: designing the solution. See you in the next article. If you need a personal consultation on the estimating the project or solution architecture I am available for it.
Don't forget to smile alright! 🤩
Also, if you liked the article, don't forget to Subscribe to get notified once a new article is published. Sharing the article in your social networks is always welcome as well.