Often times, potential customers’ first question when they have an idea for an application is “how much will it cost?” As we’ve discussed previously, the answer is almost always “it depends.” Without several key pieces of information, it’s very challenging for a software development company to predict the cost of your intended application, and even attempting to do so often requires making a number of assumptions that may prove to be incorrect. These assumptions can result in the estimated price being higher or lower than the actual cost, and in general, can provide a shaky foundation to our customer/vendor relationship.
Through our experience in taking on unique and challenging development and sustainment projects, Segue has developed an approach to minimizing assumptions and better scoping the size and complexity of the work before us. We call this a “Discovery” process and the goal is to give us a better understanding of the work and to give the customer a more accurate estimate on the cost and time needed to complete the work. The goal of Discovery is to develop an accurate and shared understanding of the work before committing to an execution strategy. We do this through three phases: Identification, Analysis, and Recommendation (IAR). This process has proven effective in capturing all technical or other related considerations for a project, and tying specific solutions or options for multiple solutions for our customer to review and choose from.
Our Discovery approach results in several deliverables depending upon the project needs, but typically include a high-level requirements document with recommended technical aspects, wireframes/mockups of the intended system, and an accurate proposal for the full development or sustainment effort. It is important to note that Discovery isn’t an added cost to the project. What we have done is taken the first necessary step of any custom development or sustainment effort and broken it out as our Discovery process, to perform that work first, before committing ourselves or our customer to an unreliable bid for the full work.
Using a Discovery Engagement
Let’s look at two scenarios:
Scenario A: The customer calls and asks “How much will it cost to build a site that works like Yelp?”
(For the sake of this comparison, we’ll say that no further detail is available. The customer has a tight timeline, and needs a number rather than a more reasonable back and forth discussion of what the requirements actually are – believe it or not, we do get this sort of inquiry from time to time)
With nothing more to go on, and no way to whittle down the feature set or intended functionality, we are left to price an entire range of possibilities, from the very cheapest (let’s say a bare-bones interactive site will be $25,000) to the most expensive (say, $150,000). This range of $125,000 represents the uncertainty we face in providing pricing, and as a result, we will hedge our bets (to make sure we’re not setting ourselves up for failure, and will be able to profitably deliver what the customer has asked for). As a result, our quoted price will probably fall much closer to the high end of the range than the lower end.
Scenario B: The customer calls and asks, “How much will it cost to build a site that works like a miniature version of Yelp but only includes nail salons in a 20-mile radius of my hometown? We’ll use Facebook for user account authentication, and it needs to be able to work on mobile devices and traditional desktops?”
In this scenario, we’ve got a lot more detail than in the first one, and have been given some important things that let us eliminate some of the potential complexity that we had to consider in the first instance. As a result, we can narrow down the range of prices to $100,000 to $125,000, a range of only $25,000, which reflects a much lower degree of uncertainty than before. This reduced uncertainty translates to a higher degree of confidence in our pricing, and, in this case, a lower cost to the customer.
It’s worth noting that the application in both scenarios is the same application – it’s just that we have more detail in the second scenario, so we can price more accurately.
So how can we best reduce uncertainty, ensure that both the client and customer have a sound understanding of what’s going to be developed, and provide accurate, competitive pricing? At Segue, we recommend the use of a Discovery engagement. The Discovery focuses on nailing down high-level requirements and getting some of the preliminary design work done, and effectively provides the level of detail required for us to give an accurate cost estimate for the complete development of the proposed application. This cost estimate for development is the principal deliverable of the Discovery effort.
Why a Use Discovery Engagement?
It’s important to emphasize that the Discovery does not significantly increase the cost of the overall development project. The work performed in the Discovery engagement is all work that would have to be done in the initial phases of the development project either way. It may be helpful to think of it as simply segmenting the project: Segment 1 (Discovery) is front-loading some of the requirements analysis and design work of the development project, while Segment 2 (aka “the rest of the project”) includes any remaining requirements analysis, and the actual development, testing, delivery, and implementation of the application.
Performing the Discovery work up-front also provides the added benefit of allowing the customer to make key design decisions early-on, including prioritizing feature development. If the cost proposal is higher than expected, we can have an informed dialogue about the costs associated with each feature or module, and make careful adjustments to the cost proposal as needed.
Costs for the Discovery effort vary based on the overall scope of the project (an enterprise system with 10,000 users requires more analysis and design than a 5-screen mobile app with a conference agenda), but is priced on a firm fixed-price basis. At the beginning of the Discovery, we provide a list of the deliverables for the effort, which may change slightly from one to the next, based on the customer’s wishes. We also assign a cross-functional team to perform the work, which generally includes a Project Manager, a Designer, a Requirements Analyst, and a Senior. Developer or Systems Architect. This team works to quickly assess the customer’s need and provide the prescribed deliverables to enable the customer to move forward with their project as soon as possible.
You may be wondering if Discovery is right for you and your project, in short it is always a good idea to fully understand your technical requirements, constraints, and enhancement needs prior to soliciting bids for custom application development or sustainment, so if you have any questions about your own needs, then you will benefit from a Discovery engagement. This approach is slightly different than what other companies may recommend, but we have seen its effectiveness over and over again, we have found that getting off on the right foot can set the stage for a long, mutually satisfying relationship.