At the recent architect forum in Sydney I was able to sit in on a round table discussion regarding rapid estimation exercises.
I’m in no way new to the process of estimating implementation time or generating effort forecasts – I’ve done so professionally for the past eight or nine years, an in the consulting space for about four of those eight or nine.
One part where I felt the rub was that there seemed to be a fairly interesting consensus (unspoken perhaps, or just not openly denied by anyone) that it’s OK to produce a costing estimate roughly inline with what a vendor or service provider feels that their client/customer has the budget for.
I’ve got mixed feelings about this kind of modus operandi. My initial thoughts is.. "ok, folks have got to eat", meaning.. no project, no pay. No pay, no food.. After all, you have to make a living.
However..
Isn’t this kind of thinking a plague within the IT industry as a whole? The ‘get it done based on what the client is willing to pay’ mentality is short changing us (those who provide the technical solutions) of decent quality and working conditions?
When the client wants X functionality over Y timeline and yet the estimated cost and effort breakdown can’t practically meet either X or Y, aren’t we continually dropping the quality bar (removing key testing/QA milestones or deferring issues.. or worse, extending everyone’s workday to 9 or 10+ hours sometimes pulling in a Saturday or Sunday here and there?
In other words, when a vendor or solution provider under-estimates, aren’t they harming the greater IT community at the same time? What happened to integrity? Giving the client an effort forecast and costing schedule based on what they asked for, and then negotiating those requirements in or out of scope to fit within a sensible timeframe (meeting quality levels) and within their budget? Isn’t that likely to lead to success over the opposite tactic?
There is a theory known as the ‘iron triangle" in which a customer is told that they have three movable choices; cost, time and scope. The customer is told – pick and define any two.
– When time (faster to market) and scope (functionality) are the priority == higher cost.
– When scope (functionality) and cost (lower or fixed) are the priority == greater time (to market).
– When time (faster to market) and cost (lower or fixed) as a priority == restrained scope (less functionality).
Even given the triangle, part of the problem is that many vendors undercut by cutting or (in some cases) dropping effort and costing in key delivery areas, in particular QA, deployment, post-delivery support, unit testing, documentation and end user training – not too mention proper handover process.
At the end of the day however, responsibility for this has to end up back on the customer’s shoulders. Caveat emptor. If you get three quotes and you take the lowest quote without either reading between the lines or even doing a cursory examination of the granular differences between the quotes, perhaps you’ll get the cheap and nasty project.
Obviously, there are plenty of bad experiences to be had even if you do fork out the money, but if you have something mission critical, do you want to place trust in the cheapest vendor?
Do yourself a favour and do the proper due dilligence before engaging a vendor. Here is a little checklist, things you should expect* to see before engaging in any type of development project:
– Draft Project Plan
– Effort Estimates
– Draft Test Plan
– Draft Technical Specification
– Architectural Overview
– Functional Requirements List
– Wireframes/Flowcharts/Mockups
– Schedule of delivery
– Hosting/other running cost estimates (for hosted solutions, perhaps bandwidth usage estimates, as an example)
– Non-functional requirements
– Project Risk analysis
– Cost estimate
– Change management/project management overview
– Understand how the vendor cost/process changes once delivery is in progress?
I’m open to comments on this topic! Am I right? Am I wrong?
I’d like to hear some kind of community feedback since this is, essentially, an ethics piece.
Do you go for a dollar figure which you think the customer will swallow, or do you give the customer an honest estimate of the functionality they are asking for?
What do you do or what would you consider doing differently?
Have I missed something critical in my analysis?
Edit: * I’d also say it’s also fair to expect to have to pay money $$ to get this kind of forecasting done with any level of reliability! A decent estimation will take a minimum of a week to about a maximum of around 6-8 weeks depending on the scope of the work you want forecasted and the size of the team performing the estimation.
