Creating better time estimates for your projects
This time of the year we usually go for our winter team building to ski and snowboard together for a couple of days. 2017 started different for us.
While we all enjoy most aspects of working remotely there are times when it is a lot better to share the same physical location. After several months of work we recently delivered an intranet application for a mid size organisation. This provided us with some breathing space and it seemed good timing to get together. Balázs picked the perfect spot by lake Balaton — a villa in a summer vacation resort offering a couple of days of uninterrupted isolation for us.
Lately we are working on more complex projects with just the planning and estimation phase spreading over weeks of intense work. Both as individuals and as a team we are constantly evolving, trying new methods and technologies, getting better at everything we do, yet we fail to create accurate time estimations of the work ahead.
Although we improved gradually over the years on this aspect there is still a lot to be done. We started the week by analysing the latest project, the aforementioned intranet application. The general conclusion was that the project was a success, initial feedback from the client was great but on the negative side we delivered about a month later and went way over budget with the time spent working on it.
This was our starting point to dissect our activities so that we better understand what are the underlaying reasons for not being able to estimate workload accurately. In this post I will give a brief overview of the findings and the conclusions we drew so far. Bare in mind that this is still work in progress.
Team work — Although we delivered several projects on a similar scale before, this was the first time when the developers really worked as a team distributing tasks and coordinating the work amongst themselves. This meant some experimenting and regular calls to discuss issues and agree on the next steps. Some of the extra time spent is accounted to the transition period, but team coordination is time consuming regardless. Some of the key benefits are that you can ship quicker, certain problems are solved easier when doing it collectively, regular code reviews result a more consistent code base and there are less dependencies when more people are involved in a project.
New technologies — You would expect that with time and experience you become quicker and more efficient. That is partially true, however web and application development is a field evolving rapidly and to keep up the dev team requires time to research the latest technologies and invest in learning them. As an example for the intranet application we used Elixir for the first time, replacing Ruby. This proved to be a great choice because Elixir is a concurrent language that leverages the whole available computing power of the server, meaning that the application can outperform Ruby without additional fine tuning. However a learning curve follows every decision like this which should be somehow represented in your time estimation, deadline and budget.
The solution around the corner — Solving new problems often take several steps with the constant feel that solution is just around the corner. The time spent on a task like this can explode and become a key factor in exceeding budgets. If the problem is identified at an early stage and communicated to the PM, you have the choice wether to absorb this and account it as part of the learning curve, or notify the client in advance that a budget increase is foreseen and ask for approval or propose a different path. Post factum this is rarely acceptable so make sure to have a good flow of information all the way from the devs to the client.
Changing requirements — The applications that we build are based on ideas from our clients. During the estimation phase we help transforming this initial idea into something functional that will best serve the intended users. Time and price estimates are usually based on the first part of the planning phase, but refining the concept and gathering additional requirements continues after approval of budget. In most cases the client also brings new ideas to the table during the development phase. Obviously this means increasing expectations while budget remains as pre-agreed.
A good practice is to prepare the client and explain upfront that the application is a living organism. While we agree on a certain feature set, reality often changes these requirements as time goes by. Looking at the budget as a bucket is a good approach. You can fit in as many features as the size of your bucket. If you want to add a new feature, you can have some from the original set replaced or you can increase the size of your bucket. Again communicating this upfront makes the collaboration with the client a lot easier on the long run.
If the bucket is too small reason with your client to eliminate the nice to have features. Aiming at a well built MVP will give your team room for writing good code and deliver a product within budget that will make your client happy.
Spotting problems on the time sheet — Once the feature set of an application is clear the dev team rates every feature card with story points. This then gets converted to a budget of time for us to monitor and money for the client to approve. Up till now logs within a project were categorised by activities (called ‘tasks’ on Harvest): Project Management, UI Design, Frontend, Development, Research, etc. When hundreds of hours are logged into these categories it is very difficult to analyse the data and spot which part of the work caused problems and where was substantial discrepancy between estimated and logged time.
To overcome this problem we now add each feature card as a task to Harvest, so when you log you would choose the project and then the feature you are working on. This way we can for example compare tasks that are rated similarly by the dev team and see how the time spent varies amongst them and look for patterns.
Budget vs quality? — We always look for the best solution to a problem and never take budget driven shortcuts. I believe that this is the attitude if you strive higher, while at the same time you need to fill those holes in your workflow to run a sustainable business. Providing quality products and doing so with a budget aware attitude are not contradictory to each other. On the contrary, one of the pre conditions of delivering a high standard product is to be able to set the way and estimate accurately what it takes to get there.
Although this meet up was more work oriented we still managed to spice it up with some fun. We had a private training session in the backyard of the villa held by Máté from Apollo Coaching. If you look for a private trainer for yourself or your corporate team in Hungary don’t miss to contact him.
We also enjoyed a glimpse of sunshine on the frozen lake Balaton and last but not least had a couple of Playstation tournaments just so we fit the stereotypes of a dev company :)
