Answering our clients’ needs with a new estimation app
Goodbyes are inevitable. And even though saying goodbye is rarely easy, in most cases, this is necessary because it allows us to move on, move past old limitations, discover new possibilities, and become much more efficient. This was exactly the case with our Estimation Excel.
Bye-bye, Estimation Excel: reasons why
A while ago, our Pre-sales team started to notice significant limitations associated with Excel spreadsheets. Due to specific customer inquiries, we needed a variety of calculations that went beyond what our Estimation Excel was originally designed for. Of course, we could have just dove deeper into Excel and expanded the way we use this highly advanced tool, but this was just too complicated — even more complicated than building a brand new application from scratch. Also, we needed to streamline our work and make our processes more comfortable for everyone involved, so that we could proceed more smoothly and efficiently.
However, we couldn’t afford to build a whole new team just to design and create a new app for our own internal purposes. We had to run this project while simultaneously acquiring and serving new clients, so it ended up being developed at the beginning by just one person.
Of course, this would not have been possible without the help of a few fantastic consultants (such as team leaders, analysts, UX designers, and project managers), who dedicated their time and energy to creating something truly worthwhile. And now we have a team that has been working on the project full-time for the past 6 months.
Most important features
Our new estimation app is going to totally replace our existing spreadsheet. However, it’s still pretty new, so it’s not fully deprived of bugs yet… though it has already reached a level of maturity that allows us to use it in our sales strategies. And we’re constantly making improvements.
Our unique calculation model is based on the PERT methodology (read more about this below) and also includes some additional variables, such as:
- resources needed for testing,
- time required for necessary meetings,
- seniority of developers,
- discrepancies between optimistic and pessimistic estimates and weighting them according to expected levels of certainty and known risks,
- overhead resulting from the size of the team,
- anticipated availability of team members factoring in sick leave and holidays.
This advanced model has been polished and refined at Future Processing and, hopefully, it will continue to serve us well in the years to come, now in the new app.
Access to the app can easily be granted by the project owner, and then you only need to log in through our Future Processing Azure AD. It’s as simple as that. Now, let’s go through all of the main functionalities, so that you can have a full picture of what the application has changed for us.
2 things that haven’t changed
1. Real time collaboration
Since this was a feature that everyone already loved, we didn’t want to change it. This feature allows multiple specialists to work on the same project at the same time. The app saves and updates data in real time — there’s no need to refresh any of the views manually. It’s both secure and easy to use, and also very time-efficient.
2. Underlying core of the calculation model
As mentioned above, we copied the calculation model from Excel, which uses the PERT formula (Program Evaluation and Review Technique) and our own overhead calculation methods. This is invaluable in terms of calculating the expected duration/costs of a project, when there are many unknown factors.
It combines statistics and probability theory, and is also called a three-point estimation, since it’s based on three estimates: optimistic (no complications occur in the project), realistic (most likely to happen) and pessimistic (worst case scenario, everything goes wrong).
So much for resembling an Excel spreadsheet! Now, let’s see what truly makes it different.
5 things that have been greatly improved
1. Technical areas
The scale and complexity of each project requires them to be split into several smaller units. Often we need to distinguish between 3 different technical areas: backend, frontend, and quality assurance (testing), so that we can make necessary estimates for each and every task in any given area, independently.
This allows us to provide our clients with more detailed and precise time and cost estimates, and — more importantly — build a team that is better adjusted to project needs. For instance, we can create a good balance between backend and frontend developers — especially if one technical area requires much more work than the other. This provides us with greater flexibility than Excel.
2. Composition of teams
Instead of having one fixed team structure for the entire duration of a project, now we can define a different team composition for each phase of a project, separately. This helps us adapt to each challenge that we face — we can plan to scale up or down, or replace specialists when one stage of project development ends and another begins. For example, we may want to replace a DevOps specialist with a security expert once the infrastructure is ready. Plus, now the entire team is also split into types of roles: productive and supporting.
Productive roles ‘exhaust the estimate’, meaning that if a task was estimated to take 100 man-days to complete, two productive roles would finish it within 50 man-days. The cost, effort and engagement of supporting roles is calculated based on the cost, effort and engagement of productive roles, and this is maintained throughout the entire duration of a project.
3. Business analysis (BA) and backlog views
In order to facilitate the process of introducing new tasks in the application, we added a streamlined view, which only shows those pieces of information that are important to BA specialists. And when it comes to the backlog view, we can effectively import tasks from Excel sheets, while still preserving their structure. This means that our app is able to map out certain columns and place values in their respective cells.
4. Options comparison
Using the Excel estimation sheet, we weren’t able to easily check how costly each phase is in each and every variation (optimistic, realistic, and pessimistic). Now, we have an in-depth view into potential costs — and this is presented in the form of an easy-to-read matrix (available in the Calculations section).
5. Cost reports
The cost reports section has been greatly expanded, especially compared to its previous version. It provides detailed information for team leads, account managers, and other executives, so that they can be fully informed about expected expenses for the given month, specific breakdown of costs, and margins. Put simply, the application allows for detailed forecasting and budget planning.
The newest feature: Risky estimates and Risk logs
Recently, we gave our application a major boost with a tool that can be extremely useful to those leaders who are responsible for finding risky estimates within a project. A Risks tab has been added to the main menu, which redirects users to a summary that presents automatically detected risks (based on estimates provided by the designated team).
But what exactly is a risky estimate, anyway?
For each task, based on optimistic, realistic, and pessimistic valuations, a weighted average is calculated. The algorithms take into account the weights that have been developed by Future Processing to better reflect IT realities (standard weights in the PERT methodology are different). The 3-point estimates are then used to calculate the standard deviation. Risky estimates are those that have a significantly greater deviation than the average deviation of all tasks.
The Risky estimates section: 2 highlights
Risky estimates summary
The risk report is divided into each phase of a project — and it contains a number of helpful features. For example, there is a chart showing the riskiness of individual phases and a histogram of optimistic, realistic, and pessimistic deviations of risky estimates for the entire project. Below this, there’s a table that shows how many estimates in a given phase have been defined as “risky”. Plus, you can see average deviations and average estimates. This allows users to get a better understanding of which phases are more vulnerable than others.
Risky estimates report
This report is presented in the form of a list of risky estimates, sorted from the most serious to the least risky ones.
Also, our app was upgraded with the Risk log section, which allows us to estimate the time and cost of specific risks, taking into account their probability.
Of course, both the Risky estimates and the Risk log sections (along with the estimation algorithm itself), are still pretty simple. For now, it’s all more like an MVP version of a bigger functionality, which is due to receive an upgrade in the near future. For example, we’re going to add information about how often a given estimate changed or what the deviation is between the current and past versions of the estimate.
We’ll be keeping you informed about any new updates, so stay tuned.
ABOUT THE AUTHOR
Adam Grabek has been working at Future Processing for nearly 5 years. He originally started as a Senior Java Developer, and now he works as a Presales Solutions Architect, providing technical consulting, initial architectural design and consultations about team composition for Future Processing’s new clients. His ultimate professional goal is to create solutions that bring real value to businesses and that are able to improve society.