How to prepare a project specification, so that a software provider can estimate the time and cost of the project with a great dose of accuracy? This question gives sleepless nights to both outsourcers looking for the most attractive offer, as well as software houses who struggle with poor budget and time estimates.
In order to find the answer to this question, we interviewed two Future Processing presales and estimation experts – Iwona Dryś, Senior Business Manager and Jakub Pierzchała, Presales Manager. Take a look at their insights on IT project estimation and presales process.
Startnearshoring (SN): What should be included in a good IT project requirements specification?
Iwona Dryś (ID): Well, the best answer to this question is – it depends. Of course, functional requirements are a must, but at the end of the day non-functional aspects such as performance and security are also very important for the stakeholders and management.
SN: So, in terms of functional requirements – what can be done for the estimates not to be too uncertain?
Jakub Pierzchała (JP): First of all – at initial stages of the project uncertainty is the reality we have to face. There’s this concept of the ‘Cone of Uncertainty’ and it comes down to the fact, that at the beginning of any project we simply don’t know exactly how long the development will take and how much will it cost. Determinants such as requirements, people, business context, technology, priorities or constraints are never the same for any two given projects. That’s why despite precision is necessary, at initial stages of the project some questions just can’t be answered.
SN: That’s clear – the earlier stage of the project we’re at, the less possible it is to precisely estimate its costs and time.
ID: Obviously. Of course, this uncertainty varies basing on many factors mentioned by Jakub, but it’s crucial to understand that if at the initial phase of the project the estimates indicate the duration of more or less a year, it may as well be 3 months or even 4 years. It’s just the way it is – the knowledge base of the project expands during the process of creating the specification. So, at later stages, let’s say at the stages of product definition, ready requirements, or detailed design – the uncertainty decreases. That’s because answers to the same questions differ at each stage, and that’s completely normal.
JP: True. Customers sometimes get frustrated when the scope of the project changes quickly at the beginning, but in fact that’s a good thing. It’s a sign that requirements evaluate and that we’re getting closer to what stakeholders actually need – or at least we’re trying to. That’s why it’s important to develop a certain amount of tolerance for uncertainty, especially at the very beginning of cooperation with a software house.
SN: But it’s the job of a service provider to minimise this uncertainty.
ID: Yes, it is. The responsibility for an accurate estimate rests on the shoulders of the software provider. The outsourcer is usually not a software company and software development is not their core business. And that’s good, because that’s what we’re there for – it’s our job to solve business problems with the use of technology. The outsourcer simply needs to have a business idea and a will to translate it to a working software with a help of a third-party provider.
SN: That’s not all. The more input the customer provides, the smoother the estimation will go. Isn’t that right?
JP: Of course, the software house needs as much details on the project scope and its current stage as possible, but there’s the flipside of this coin. In order to precisely tailor the requirements, we need to make use of our in-depth experience and expert knowledge during the presale process. That’s why we have a habit of involving senior engineers and business analysts with domain expertise in the estimates to maximise their efficiency and accuracy. The more experienced and skilled people are involved in the process, the less uncertain the estimates are.
SN: So, a good estimate depends on both the input on the side of the customer, as well as on the knowledge and experience of the supplier?
ID: Yes, but there’s more. Business is never simply black or white. Sometimes at a very initial phase of the project stakeholders require very precise answers to rely on in the process of deciding whether the project will be given a green light or not. In this case the risk related to uncertainty increases.
SN: What can we do to minimise the risk of uncertain estimates?
JP: There are two best ways to choose. The first one is to involve a business analyst for the estimates – especially if you want to cooperate in a Fixed Price model.
ID: To precisely prepare estimations it is often a must to involve a business analyst. They precisely state the requirements and clarify uncertainties. They also make first assumptions and perform initial analysis. And as Jakub mentioned before, the phase of analysis is beneficial especially in a Fixed Price partnership. In this model, the customer wants to pay as little as possible, and the provider wants to deliver the solution as quickly and with as minimised costs as possible. In this relation, a precise specification and well-determined project backlog tips the balance in the favour of a business analyst. Bearing in mind the requirements form the basis of a contract, they can’t be unclear or uncertain. This causes frustration and misunderstanding.
JP: The second way is to establish a partnership based on Time and Materials contract. In this type of cooperation, the software provider aims at delivering the best possible solution, so that the outsourcer will be happy to continue their business relation. Here we’re usually more likely to skip a thorough initial analysis phase, as the proof will be in the pudding. So instead of an upfront detailed analysis we go for frequent inspections during the development process, to ensure that we’re building exactly what’s actually needed. However, in this case the costs will possibly be higher.
ID: What’s more – when cooperating on a Time and Material basis without a decent project specification, the customer must prepare to be directly involved in the process of incremental software development. Here we follow the tactics of small steps and constantly consult each sprint result with stakeholders, what can be time consuming.
SN: You’ve mentioned the role of a business analysts. I know that some outsourcers don’t see the value of their involvement in the process. Why is that?
JP: Well, some may have the impression that an analyst is expanding and stretching the backlog for the benefit of software provider. But that’s far from the truth. Business analyst is conducting a series of interviews, calls and conversations with stakeholders, therefore gathering requirements the backlog is comprised of. This involvement can be minimised and serve only for the purposes of presales process, but there’s also another way – some customers decide to go through a commercial service of Analysis and Design. It results in a precise, tailor-made specification they have copyrights to, that will be later used in the process of choosing the best possible software provider.
SN: Are you saying that the process of Analysis and Design – gathering requirements, building backlog etc – can be separated from the process of software development?
ID: Yes, that’s true and it serves only for the benefit of the customer. Thanks to a precise specification created as a result of a thorough analysis, the outsourcer has a great input to present to other software houses from their shortlist, so they can prepare their estimates. This ensures that the customer is truly comparing offers of the same product.
JP: When approaching several software houses with a Request for Information, you can’t be sure they are actually estimating the same product. Some will include certain functionalities, some will exclude other and at the end of the day you end up comparing apples with bananas and wondering where the differences in price and time estimates come from. In order to avoid this – put particular stress on preparing a proper specification with the help of a business analyst.
SN: Let’s say I’m still not convinced about the benefits of involving the analyst.
ID: It is also important to understand that it is time consuming to precisely gather requirements. Of course, we can depend on a rough guess of what the actual needs of the stakeholders are, but it’s much more effective if we can involve them in the process. This results in a high quality, realistic scope estimate and maximises the chances of delivering a solution that they actually need. It also ensures that both outsourcer and service provider are on the same page and understand given issues in the same way. And that’s what business analysts are for – to minimise the frustration and maximise effectiveness.
JP: Another benefit of a thorough analysis during the presale process is that it creates an opportunity to challenge the business idea with its end users. This is crucial! Each software has a purpose to serve, and it often turns out that while on a high level this purpose is similar in the eyes of both management and system’s end users, when it comes to details, what management imagines may be far away from what users expect to have. All these views must be included in the specification prepared by the analyst. Otherwise, there’s a risk the software will be useless.
SN: Does it mean that the bigger the project is, the more important it is to focus on an in-depth analysis at the early stage?
JP: Yes and no. If you skip workshops and interviews and don’t pay sufficient attention to preparation of specification there’s a high chance, you’ll end up with the software that neither solves your business problems nor answers your expectations. Nevertheless, in short projects that are relatively inexpensive, changes and adjustments are usually possible. However, in more complicated IT projects it may turn out that desired alterations are simply too expensive to implement, and the whole project falls apart.
ID: That’s true. And one of the most popular reasons for this kind of failure is the lack of a precise backlog in the first place. You can focus on preparing a detailed specification at the very beginning of the outsourcing journey and then face only minor challenges, or you can skip this stage and choose Time and Materials model but prepare to be constantly involved in the project that may cost a bit more. Usually customers who understand this are the ones that have learned from their past mistakes, when they ended up with unwise investments and useless software.
SN: Thank you for this conversation. Now we’re sure that a well-prepared specification created by skilled professionals is a must in terms of precise IT project estimations.