Factors that impact estimations
This is article #2 in the series of posts on estimations in outsourced teams based on my experience working in software development with Flatstack. The goal of this series is to create more transparency regarding remote teams and approaches that are employed.
In my previous article we reviewed estimation processes based on client’s business maturity as well as software development methods that you can consider. Within this article, we’ll be taking a closer look at some reasons that cause missed deadlines with reflection to cases from my experience. Following each provided example, I’ll be sharing lessons that we carried out and best practices that we put in place as a result.
So why are estimations often off? It might seem that a development team is the only one who is responsible for estimations. But it’s just an illusion, as for realistic estimations there are quite a few components involved.
There are instances when even with all required details at hand it is still difficult to provide estimations. One of the most common examples in the outsourcing sphere is legacy code. In other words, instances when clients come with an existing product and code base, but plan to grow it further. Consequently, at the beginning of collaboration development team is not yet familiar with the code base, weak points and the condition of a project in general. Therefore, it’s frequent that initially the timeline is followed but with significant or (more rarely) insignificant delays.
There was a case when we made estimations in one of the new projects and missed the targeted dead-line. It turned out that at the stage of investigation we didn’t fully realise the impact of extensive interdependencies (poor code quality) within the system. As a result it caused prolonged development.
Based on this experience we have established an approach that helped us avoid such instances in the future. Specifically, before making estimations we agree with a client to kick-off project and work a few sprints according to the priority list BUT without a tie to any due date. As a result we would get an average velocity of a team and further on plan and provide timelines based on that performance data.
Product owner (a.k.a. client) needs to be on the same page with the development team to ensure efficiency of efforts. This is so critical, that at Flatstack each team has their own client manager who is responsible for communication between a client and a development team. Specifically, managers are taking care of all the organisational chores like reporting processes, meetings facilitation and other team work related activities. This way developers can fully focus on tasks implementation and necessary investigations for better solutions. To be fair, I have to say that majority of software development companies are employing this approach.
Getting back to the matter of estimations, it is very important to have initial requirements from client side documented thoroughly so that there are no misunderstandings regarding the work-scope. In fact, detailed tasks is #2 in my list of how to increase development team’s efficiency, which is also the key to on schedule delivery.
There are three problems to incomplete documentation:
- it creates spaces for misinterpretations;
- it prolongs the preparatory phase, since the development team will have to clarify specifics of a feature or scenarios that were not covered;
- with limited information team will provide very rough and often far from reality estimations based on their understanding of a feature;
Agile methodologies do imply flexibility in software development, but you need to keep in mind that significant plan/requirements change during the kicked off development cycle means the team has to pivot to meet new needs. Therefore some of the work that has been done so far might become obsolete or require significant adjustments resulting in prolonged development time.
In my management practice we did have quite a few projects in similar situation. For instance, we receive feature specification that is not complete or client has a big picture, but is not completely sure of details. The right thing to do in such cases is to over-communicate with your clients. Do a favour to both the client and the development team:
- ask any additional questions that might clarify the goals and features that are being requested,
- discuss concerns regarding incomplete understanding openly,
- explain transparently the effect of changed requirements when the development will already be in progress.
By doing so you’ll ensure that everybody are on the same page and are aware of any possible challenges involved.
Both a development team and a client have to commit to the set deadline and specified requirements. This means there has to be no (or minimal) distraction for other chores or additional unrelated tasks.
In case there are other requests submitted, in addition to estimated work-scope for the deadline, the team will take them into development if so instructed. However you might have to either incur additional costs of adding more developers or accept the fact that initial list of requirements won’t be fully delivered.
1 team member can do 3 tasks over the course of a sprint. If 2 other tasks have beed added, it means that either:
- there has to be a trade off for 2 tasks from the initial list of requirements,
- additional work to be done in another sprint,
- another person to be involved to undertake those additional tasks.
Even though this might seem obvious, quite often we receive requests for “small” adjustments when a team is already involved in development of a big epic. Please note that no matter how small a request is, big number of them will impact the delivery of higher priority tasks, which eventually means a missed deadline.
To ensure there is a dream team that goes above and beyond, there are team planning efforts of multiple top managers put into play. Thus the teams are compiled. Team members work alongside each other and build up not only features, but also knowledge base of a product they are developing; this is especially true for long term projects. Therefore, to keep the momentum going, it’s better to minimise changes to the team. However there’s another side to that as well — new professionals can also add fresh insights and perspectives, so rotations can be beneficial and “healthy” for projects, too. Just make sure you plan them well.
Knowledge within a team has to be shared and preferably documented, so that when rotations are taking place the learning curve is shorter! Whenever there is an instance that only one (or limited number of people) within the team are knowledge keepers, it raises risks.
For me it was lesson learnt the hard way in one of my projects. Team lead was our key technical expert and the only one who was fully aware of the system’s composition. When he went on vacation and some rotations took place not only the velocity of the team has dropped, but we also missed part of the requirement during implementation. Thus development took longer than expected as additional time was needed to apply extra fixes.
To avoid such situations in the future, we now gather before any team lead’s vacation to review closest priorities and to put critical points or anything that requires additional attention on the team’s radars.
Unexpected and unplanned rotations within a team possess relatively high risks as well. Thus communication with team members is vital. Whenever there are good terms between the team members the chances of somebody taking an unexpected turn are minimised.
I’m convinced about positive effect of 1-on-1 discussions and just decent work relationships between team members. Thanks to that, I more often than not was among first people to know about somebody’s considerations regarding next career move. Thus I had a chance to think of measures to take to stabilise the situation upfront.
It’s natural that talent decides to move on at some point and that’s OK :) But what is not OK is to put the rest of the team members “under the gun.” That’s why creation of all inclusive atmosphere and great team spirit are keys to stable teams. Talk to each other.
* This one is especially relevant for startup companies with limited experience in software development. Well, it also applicable to overly sceptical individuals who decide to give outsourcing a chance…
You are a client and we understand you have a lot of responsibility for the product. But as a development team, we do want to take off some of your headache. Even though client’s involvement is very much appreciated by team members, don’t overdo it :) Instead, try to share the problems that your product is facing — it can be anything: from business objectives to bugs. Let the team look for optimal solutions, usually they will suggest a more efficient, solid and often faster-to-implement approach. After all, they have been working in development for years, might be the case that they have already solved a similar problem. Stay open, let the development team take ownership of what they are doing. After couple of years in development, I can surely say that developers grow to feel as part of the client’s team if they are given a chance to.
As a client try to have neutral instead of negative perspective on an outsourcing team, you went for it after all already. Let them build their reputation in your eyes by their real actions, not by “could be” actions. Otherwise you’ll be ruining experience for everybody — you will be stressed out all the time and the team will feel demotivated. It is in the best interest of everybody to make your product succeed — if so, you probably will want to advance it further and the team will be involved in development of new features.
- Quite recently we had an amazing team as our clients, dreaming and putting all effort to launch their own startup. They were young, eager to achieve great heights and open to development team’s suggestion. Thanks to that, we all felt like one big team. Each of us was contributing to the maximum of their expertise level — our clients were rocking the business logic and preparing most detailed specifications for us, developers were suggesting the best approaches to tackling the given tasks and as a manager I was setting up processes that made the team even more efficient. It was a blast working with them! Just a little over a year we have completed two full applications! Till today we have the warmest memories about that experience.
- At about the same time there was another startup client that another team within the company was working with. The idea of the product was amazing! At the beginning the team was really thrilled to work there — on internal demos we’ve heard very exciting stories and plans of the team regarding the technologies that they are considering to use for efficiency. A lot of people wanted to participate there. However that didn’t last long. Soon we realised that our suggestions and even concerns were not processed by the client side, thus often least optimal solutions were given a go. Not surprisingly that negatively impacted the product. The team was very demotivated, excitement that once was there disappeared altogether… Only sad sighs were heard whenever questions were asked about how things were going there. Soon afterwards the cooperation with that client was terminated.
Those were definitely two extremes that we got a chance to experience. However, the majority of our clients usually located somewhere in the middle of those boundaries.
Looking back at those experiences, there’s just one thing to conclude — attitude of a client does make a big difference too. It can either be a huge motivator for a team to rock or a demotivator that will slow the team down.
You can read through the lines of each example — setting up realistic expectations, providing transparency and building up team spirit are the components of fruitful partnerships. As project managers — we are the “glue” that brings everything together. We are playing a big and an important role — depending on our efforts with all the stakeholders, cooperation on a project can end up being a blast for everybody! Make it your goal! :)
Please note that within this article I’ve shared insights that I gained within my project manager career while I worked at Flatstack. One thing that made me fall in love with the company is one of the core values:
“Innovate, Make Mistakes, Learn.”
During our careers all of us are going to make mistakes — it’s inevitable, but what important is to take out valuable lessons that will guide us further and help us excel.
I’m preparing another article on steps for more realistic estimations that helped me quite a lot for my work as a manager. Stay tuned!
If you find this post useful please click the 💚 below and be sure to follow me for more articles on software project management!
Check out my previous articles: