Estimation of new projects in custom software development solutions may seem like an easy deal at first sight, but it’s not. Failed estimation causes numerous business troubles such as the loss of clients’ confidence, financial penalties, overtime, etc. Unfortunately, many teams start to give more precise estimates only after certain failures in the past. This learning process may be quicker in case retrospectives are conducted after each project. Documenting and sharing lessons learned across other teams in a software product engineering company, using appropriate methods of estimating relevant for each new request, anticipating risks – all this can help estimation process development.
There are various tactics and methods of estimating new projects in software development services: three points estimation, analogous estimation, expert judgment, parametric models, etc.
But in this article, we would like to turn your attention to considering the risks or complexities of incoming projects when estimating. This is because failing to see risks is one of the most common reasons for project failures. This happens regardless of project size, type, budget, and scale. An example of a risk underestimation is Denver Airport Automated Baggage Handling System. This case was described in Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister or Boeing 787 Dreamliner.
Managing risks is a big area of knowledge to learn for teams to be more efficient. We would recommend starting with simple things, at least to begin considering them at the early stages (some teams are very optimistic, so you may see estimates without any risks included at all). It could be any method of risk assessment; you may even try to guess how much buffer time you should add for risks. It would be better than to hope for the best and think that your project may go perfectly. Of course, the next questions would be how big this risk buffer should be, how to calculate it more accurately so that you don’t add too much, and not to scare a client with a huge estimate.
There are several strategies for dealing with risks:
- To avoid risks – just to avoid risky projects or certain complex project items. This may lead to missing good opportunities as well.
- To restrain risks – put enough effort into an estimate which will be used if the risk happens.
- To mitigate risks – anticipate some measures that will reduce the potential damage in case they happen.
- To dodge risks – just to cross fingers and hope that the risks will pass you by. This strategy is not suggested unless you are extremely lucky.
It’s recommended to brainstorm, list all possible risks, think about risk realization probability and how to react if that happens, what to do to mitigate a certain risky point, how to monitor risks during development, and keep the risk register up to date.
In case you have no risk management strategy, a good point to start would be to compose a list of risks you have already met during your experience. An example of such a list is provided below:
- Existing source code, ongoing project
Description:
The team needs to work with the source code from another team or take over an ongoing project. The team needs to investigate the source code, assess the code quality, and identify elements that should be refactored to work with the code efficiently. The team should also assess the project using this source code from a user perspective to understand the system flow in general.
Tips:
Request the source code documentation before estimating, set up a meeting with the previous team if possible. Ask a client or the previous team about the issues met during the previous development. In case the project is supposed to use a fixed cost model, it makes sense to start with the source code analysis and only after that provide an estimate.
- Integration with popular 3rd party API or usage of popular libraries, plugins, or CMSs which the team used before
Description:
The team needs to integrate popular APIs, libraries, plugins, or CMSs into a project. The team worked with those things before, has good experience with them, and understands pitfalls and possible issues related to such integration. Popular libraries usually have a good community and support so even if a new issue arises a solution could be found quickly.
Tips:
Check if all proposed plugins and libraries are compatible, check the versions which were used before vs. requested versions, investigate the changelog if required. Recall issues met with those plugins during the previous development and how they affected the timeframe.
- Integration with less popular 3rd party API or usage of less popular libraries, plugins, or CMSs which the team used before. Usage of custom libraries developed by another team which were used before
Description:
The team needs to integrate API, plugins, or libraries which do not have a good community, or which were developed by another team in the company. In case an issue arises, there is a chance that someone in the company faced it before so the solution can be found in a reasonable timeframe.
Tips:
Make sure the libraries or plugins have minimum acceptable specifications and the specification is in an actual state. Check the versions and changelog. In case a library or a system was developed by your company, check if the developers are available and conduct a meeting to form a better vision of the complexity. Add an appropriate buffer to the estimate.
- Usage of a new framework, API, library, plugin. Integration with an unpopular CMS or tool which the team didn’t hear about before
Description:
The team needs to use a brand-new API that hasn’t got a wide community yet or the team needs to work with some obsolete or rarely used CMS or library.
Tips:
Make sure at least minimum acceptable specification is available. Check if any paid support is available (include the price into an estimate). Add enough buffer time into your estimate and inform a client about concerns. Document all issues you met with the library or API during the development, inform the client promptly, and open a ticket in a bug tracker of the library (if available).
- Not enough available developers
Description:
In some cases, developers have to work on several projects at the same time. Also, if a support period of a previous project is ongoing, developers may be distracted due to bug fixing requests.
Tips:
Such cases require additional coordination and synchronization. When one developer starts working on two projects at the same time and both are long-term projects, it makes sense to allocate at least a part-time backup resource and start urgently looking for extra resources. The cost of such situations is higher (due to possible overtimes) and the productivity is much lower because developers lose the flow and have to switch between different contexts.
- Time and materials project with an unstable workload
Description:
In case you have less than 4 hours per day per person workload, developers either should be idle (on internal projects) or should work on a parallel project. It’s hard for developers to switch between the contexts of two projects, moreover, a developer may be busy with a critical task on one project while he was requested to work on an urgent issue on another project.
Tips:
Such cases require additional coordination. The client should be informed about not having enough workload. It makes sense to put a project on hold and accumulate a reasonable number of tasks in case there is not enough workload for more than 2 weeks. “Dynamic costs” model should be introduced to the client (hourly rates may be higher when the workload is lower).
- Fixed cost project with a very brief or vague specification
Description:
It’s too risky to sign a fixed-cost contract while having uncertain requirements.
Firstly, it will be hard to prove that one or another feature was out of the initial scope. Secondly, the requirements could be added (disguised as clarification of in-scope requirements) during the development, and the team will not be able to finish the project in time. Possible overtimes may appear which can worsen the team spirit.
Tips:
It makes sense to start with a thorough analysis phase. Business analysis services will involve the BA working with a client for as long as they need and converting business needs into functional requirements. Also, the BA can help the client to better understand the expectations of the target audience and better prioritize features according to their business value.
If it’s not possible to have enough time for the analysis phase, we can also put into a contract that if a certain point is vaguely described, the development team chooses the most suitable implementation approach based on their own decision.
- The product owner has poor availability for a technical team
Description:
This situation leads to an unsync between the team’s understanding of the requirements and the client’s expectations. The team may receive information about deadlines, business needs, and requirements too late. The team will not be able to inform the PO instantly about the impediments.
Tips:
The team should inform the PO about not having enough availability as soon as possible in order not to accumulate problems. In case the PO cannot make himself available enough for the team, the PO should be replaced.
- A distributed project where a technical team needs to work with another team of the same company (Could also be in different time zones)
Description:
In case such teams didn’t work together before, they will need more time for synchronization during the early phases of a project. Also, there may be conflicts if two people with strong technical skills have different visions regarding implementation. The team will need to collaborate during limited hours. There could be cultural differences that may complicate the communication. There is also a high possibility of overtimes.
Tips:
There should be additional time added to the estimate for synchronization. It’s better to assign the project teams who worked before. You need to make sure there are no personal conflicts between teams/developers. National public holidays should be considered during project planning. It makes sense to check upfront if developers from different teams can understand each other well during voice meetings.
- A distributed project where a technical team needs to work with an external team
Description:
The same points as above, plus if the external team is on the client’s side, they may have more influence regarding technical decisions.
Tips:
Time and materials or a Dedicated team model are preferable here. The teams should openly discuss impediments and inform a client about them promptly.
- The client has already defined deadlines that are tighter than the technical team estimated
Description:
The team must work overtime, the team should add more developers who work simultaneously, which complicates the merging process.
Tips:
The client should be informed that the risk is high before starting a project. It’s important to ask the client what the reasons for the deadline are. I.e. if a client has a public event where he needs to demonstrate the product, it makes sense not to implement all points completely but to focus on UI and some hardcoded data for presentation and then complete the rest after the event.
In case the release date was announced before and there is no possibility to move it, it makes sense not to spread efforts to all features but to define the ones which are more important for the users and that won’t be risky to implement.
- The team doesn’t have a tester or QA hours were cut
Description:
The client wanted to cut the budget and not assign a QA person to the team, hoping that developers could handle QA testing services by themselves.
Tips:
It makes sense to explain that the cost of 1 hour spent by a developer for testing is higher than 1 hour spent by an experienced tester. The tester can also find more hidden bugs and do regression testing more thoroughly.
Of course, this is just a basic example of common risks and complexities that development teams meet during their project, and which may affect the number of hours spent on the project. Each organization and team should compose their list of risks depending on the upcoming project and considering their experience, processes, and other specifics.
It is important to remember that even small efforts in risk management are better than no attention to risks. Let your projects are successful and the risks justified!
