How to Estimate a Project and Avoid Problems - A Great Challenge in App Development

Often the tasks and projects are underestimated, there are a lot of (unpleasant) surprises, the deadlines are not met, the client is stressed out, and the pressure put on the team is almost tangible.

Nevertheless, we have to do it. We have to estimate a prospective project and that’s unavoidable. What we can do is stick to several pro-tips that will possibly make the whole process easier, the estimates more accurate, and the client more aware of all the tricks and risks we may encounter.

Pre-estimation:

Collect information

First of all, understanding the product is the base of the estimation, so gather all the documentation that was sent over during the sales process. Sometimes the clients send over wireframes, moodboards, briefs, business requirements, market analysis. Every piece of information is valuable, so don’t let anything get by you you.

Get rid of the unknowns

After getting to know the business goals and project requirements, list all the knowns, unknowns and risks. As soon as you get them, you can find answers for the questions and clear up any doubts. Be inquisitive, ask the client to provide as much as they can. This will allow you to prepare a list of estimate assumptions - the base for the estimates. You cannot build great software on weak foundations.

During estimation:

Engage a representative of every field the project touches

That goes not only for particular technologies, but also Product Design, Quality Assurance and Project Management. Having input from them at this stage will certainly prove to be valuable later on. In the end, all these areas are interconnected and the success of a project depends on their close cooperation.

Stick to the Definition of Done

Work in Scrum relies on a couple of principles and the Definition of Done (DoD) is one of them. This is a list of the criteria that have to be met in order to deem a task completed. The DoD is worked out by every team on its own, although some points may be shared throughout all Scrum teams. If it says that extra time needs to be budgeted for testing - add that to the estimation. If it says that we have to support, for instance, Internet Explorer 8 - extend the estimation to include supporting obscure browsers. Every special requirement may potentially extend the delivery time.

Perform a sanity check

Remember, we have developers from various seniority levels. There is a difference in estimates done by a senior leader, a senior developer, an experienced regular developer, or a regular developer fresh out of juniorship. The estimates should take into consideration who made them and who will work on them. Any discrepancy in seniority levels should be analysed and noted.

Avoid rough estimations

When something is unknown it cannot really be estimated realistically. Base your estimations on facts, your expertise or previous experience, because basing them on unknowns can only generate more uncertainties. This is why you need assumptions that are shared with the whole team. If someone asks you to read a book you cannot simply say “Okay, I will do it in a week”. What if the book has 800 pages, is printed using a 5pt font, is written in a foreign language and, on top of that, you have already planned to clean the whole house that week? All these specifics affect the estimation. That’s why you cannot tell the clients “Okay, a landing page is going to take us 2 weeks”, because we do not know what this landing page will look like or what it will contain. Every project is unique and has to be carefully analysed and estimated.

Post-estimation:

Share the estimate

Every estimation should be recorded and published internally. Ideally, every one of them should be entered in the Project Estimates tool. As a company we use Salesforce for this purpose. The author of the estimation should be known in case any questions come up once the project is be ready for kick-off.

Re-estimate when necessary

Don’t be afraid to re-estimate! In case of any significant changes to the scope, an updated version of Project Estimates should be published with a comment. This way a cross-check of all the estimates throughout the duration of the project can be easily performed. Be transparent with the client and the team about what has changed and how it affects the initial estimate. Keeping all the project estimates in one tool not only ensures transparency, but also may increase predictability and improve the whole estimation process.

Beware!

Big projects

The project seems big? Looks like 6 months of work or even more? Do a scoping session! A quick expert call might not be enough. You need to take a deeper look into things, talk to the client, take some time to properly estimate the MVP. The biggest difference between a scoping session and an expert call is the amount of time devoted in the pre-project phase. The longer the project, the more time to get to know it is needed.

Bigger projects

The project seems even bigger? Do an estimation workshop, or even a PDS (Product Discovery Sprint)! Spend a couple of days analysing business needs, profiling the users, figuring out stakeholders’ needs, and creating a Lo-Fi prototype. All of these will help you a lot with understanding the project, and prepare solid foundations for a really big undertaking. This will also be a great moment for the whole team to exchange their viewpoints and work out a common approach with the client.

After the project starts

Check the estimates during project onboarding

When a new person joins the project, he/she should take a look at the project estimates and provide feedback as the person who will actually get the work done. Re-estimations should be added in the Project Estimates tool. This may change the initial estimates, but will get you one step closer to the actual scope that will be implemented.

Always re-estimate after the design phase

Once the designs are ready, the initial assumptions may be affected. New restrictions may come up, or the initial assumptions might turn out to be irrelevant. It is good to know where you stand after each project phase is finished. Designer-Developer cooperation is crucial here, as designs affect development, and vice versa. Communicate efficiently, ask questions, work together on implementing solutions that are doable for both sides.

Check the estimates on a regular basis

Re-estimate after one month from the project’s start and then every 3 months. Confronting project estimates will prove to be valuable in the long run and the client will definitely appreciate it. Also, every change in the scope should be added to the estimates to show the client how the initial assumptions have changed and how they affected the timeline. Changes in scope will come, for sure. You need to remember that even one small change may affect the timeline.

Be transparent with the client from the beginning

Let them know that estimates can and will change. This can save you, your team, and your client some very stressful situations.

These are just a few things to look out for, but every case is different. Underestimations can cause a lot of stress for everyone engaged in the project. What you need to remember is that estimates are exactly what they are - evaluations, projections, guesses. Even the dictionary lists “fact” as the opposite of “estimate”. We are doing the best we can to make them as accurate as possible. That’s why we take good care of the projects before we even start them.

Remember: be cautious, reasonable, transparent and ask a looooot of questions. Better safe than sorry!