If you’ve ever engaged a vendor on a software development project, the vendor probably gave you an “estimate.” You may ask, “Why can’t the vendor just give me a pricing schedule or a firm quote?”
Software development is a precise way of automating an imprecise process. It is very hard to use a programming language to translate business rules to a computer, because computers only understand 100% true and 100% false. A business process that only happens “sometimes” quite literally does not compute. If you can describe the rules that govern the process of your business in 100% of scenarios in 100% true/false language (no “maybe” allowed) then it would be theoretically possible to precisely calculate the effort involved in a software project (on a related note, the likelihood of having any bugs would also get pretty close to zero).
Another issue software vendors face when we put together a project estimate is a modern world in which the way you run your business is constantly changing. We’re all fighting a battle just to keep up with changes in the market, staff turnover/competencies, and evolving business processes to maximize operational efficiency. Software projects take time to implement, and it’s increasingly likely that a requirement that made sense at the outset of the project may no longer make sense a few months later when the application is deployed to production.
To combat the challenge of change, Entrance employs an agile software development methodology that allows the software requirements to morph over time as the needs of the business evolve.
The “iron triangle” of project management is well established: scope, schedule and budget (as the saying goes, “pick two”). Entrance typically engages with clients by fixing the schedule and budget, which allows the scope to adapt.
To set schedule and budget for a project, Entrance identifies the make-up of the team needed to achieve the project objectives. By identifying the team in advance, Entrance can predict the project “burn rate” with a high degree of accuracy. If we know how many people are working for how long, then schedule and budget are known.
In addition to setting a budget, Entrance recommends establishing a project contingency budget as well. Typically, we recommend a 20% contingency. The contingency may or may not get used on a particular project but it is not uncommon for a project to go into the contingency budget. If your vendor gives you one number for an estimate (i.e., no contingency or no budget range), then it is advisable for you to add your own 20% contingency for budget planning purposes. Frequently, contingency budget is used on agile projects to address additional scope that may not have been originally anticipated. However, the project sponsor ultimately controls whether or not the value proposition exists to justify moving forward.
By staying engaged with a product owner and project sponsor via semimonthly iterations in our agile process, we have achieved great success in meeting objectives without having a fixed scope up-front. In the agile process, contrary to what you may think, we actually do more planning than in a traditional “waterfall” (all requirements identified up-front) approach. Because we work in time-boxed iterations, you are able to see progress regularly and make small course corrections as we go. By allowing the scope to adapt to your needs we you in the driver’s seat to ensure that the implemented functionality meets your most current business requirements.