No project starts before the parties agree on its key aspects: cost, duration, and scope. These parameters are equally important, but it’s the cost that usually becomes the governing factor when the final decision is made. Cost is what top managers look for in executive summaries and what defines whether the project will fit into the yearly budget. Therefore, cost estimates provided by bidding vendors have to be detailed and accurate enough to realistically reflect the complexity of the system to be built and the severity of expected risks that may be triggered in the course of the project. But what does it really take to create a good estimate that will set expectations just right?
It takes two parties to produce a viable estimate
Many people say that estimation is an art, and it may not be too far from the truth. When you start working on a painting, you may have a general idea of what you are going to portray, but the nuances are very vaguely outlined in your mind, if at all. You may expect to complete your work in two weeks, but there are plenty of factors that can kick in and set you off course. Estimations, especially in the software development business, are very similar in this respect and are, in fact, much more complex because it’s not just you and your speechless canvas – it’s you, your customer, and quite often third parties.
Software development estimates are very different from other estimates in areas unrelated to IT. Even if you are doing something difficult like building a house, you have a plan right from the start, know the number of floors and windows, and can calculate the exact amount of materials required for a particular activity (like painting the walls) or area (a kids’ room, for example). In software development, a standard task can be completed in a number of ways and the very architecture of the application can change dramatically depending on the discoveries the team makes or a sudden change of the customer’s needs.
In agile development – and agile in some form is what most developers use these days –requirements are provided by and discussed with a product owner, a person in the customer’s organization who is responsible for working with a vendor on a particular project and delivering the final product to the organization. This role is very important, so as a vendor, it is in your best interest to establish a good rapport with this person and spend as much time as possible discussing user stories, business flows, and other aspects of the product as you progress along the timeline. In simple terms, it means that the process of collecting requirements is not a one-time, pre-launch operation – it continues throughout the project, and it involves two sides to get the job done.
So how do you ensure that both sides are doing their very best to produce a reliable cost/duration estimate and plan the project?
- Explain the true purpose of the project
It’s not uncommon for customers to omit this part as something not really important. However, the goal of the project defines the scenario of its execution and the overall delivery approach. For example, a customer may need to roll out a product with certain functionality by a specific fixed date to secure some shelf space in a major national chain of stores. Or they need a proof-of-concept project completed before the annual meeting of the board of directors. If this information is not explicitly explained to the vendor, the latter may go in the wrong direction and misplace priorities.
- Get your priorities in order
If business priorities are not clearly articulated to the vendor from day one, things that are really important for user enablement may be pushed back to future releases, while the much less relevant features that require more effort (and more time!) may be brought to the front. It is not uncommon for vendors and customers to be out of sync in regard to the business value of each delivery. Developers are prone to focusing on technically complex and fundamental tasks first, but if the customer needs to demonstrate progress to senior management on a regular basis, it will require a different, value-driven approach with smaller, yet meaningful, deliveries made every 3-4 months.
- Know your end user
As a Product Owner, you are tasked with interviewing your end users, if possible, and putting together a list of requirements based on the needs of particular individuals or user groups. These requirements will then be converted into user stories and used by developers to deliver the necessary functionality. However, it’s extremely important that these requirements do not come off the top of your head and not from your understanding of users’ needs, but directly from them. This true voice of the customer often contains minute, yet essential, details that may be lost to someone operating on a higher level.
- Get your definitions straight
If the customer says that they need an MVP by December, it means that they need a product that will be able to demonstrate the core functionality without the secondary blows and whistles and fulfill at least one important business scenario. Once in place, an MVP helps to practically test a hypothesis and collect valuable feedback to be incorporated into upcoming releases. If you are a vendor, don’t overcomplicate the design of the MVP, do your best to provide a realistic estimate, and focus on polishing the first version to perfection. If everything is done correctly, there will be more work and more versions, but you have to get the first time right!
- Pick the most appropriate cooperation model
Estimates largely depend on the cooperation model chosen by the parties. If your customer insists on a fixed bid, you really need to take a deep dive into the project requirements and analyze it on a very low level. Sometimes, a fixed bid simply won’t work due to time constraints or risks associated with third parties or integrations with other systems. In this case, a time-and-materials range estimate with a cap will be the second best choice. Every software development company has its own established practices in relation to selling their services, so act accordingly, but remember about the balance of interests and potential pitfalls. You shouldn’t let yourself get caught in the fixed bid trap and you shouldn’t leave your customer in the dark about the projected budget and duration once you start your project under a T&M contract. Managing your customer’s expectations and informing them about changing projections is the only way of avoiding unpleasant conversations when you exceed the original “approximate” estimate.
- Propose a discovery stage to increase estimation accuracy
A discovery or business analysis stage is a perfect remedy against doubt and uncertainty. Not only can such a phase do away with “guesstimates”, but also reveal needs that the customer may not have anticipated. A business analysis phase documents the requirements in great detail provides clear definitions for every role and function in the system and helps make your quote as accurate and realistic as humanly possible. In addition, it may contribute to the customer’s understanding of the product and its future on the market.
Getting started with your project
If you want your project to be a success, you need a vendor that understands the complexity of estimating software development projects, has enough experience for a critical outlook on the project development lifecycle, has established development practices, and never attempts to win by offering the lowest bid. Cortlex possesses all of these qualities and is always ready for a constructive dialog about your project. We’ve been on the market for years, made our mistakes, learned our lessons, and know what it takes to deliver projects on time and within the budget. If you’d like to give our team a chance to quote on your upcoming project, please contact our sales department. We will make sure that your first experience with Cortlex is hassle-free and thoroughly enjoyable.