As a Project Manager, I have seen estimates in all forms - points, days, months, hours, mario coins, etc. Many say estimates in Software development are garbage and significant margin of error should be the expected norm. I believe this perspective to be true if estimation is conducted in a vacuum vs. as a means to have a conversation with prospective clients about what it is going to take to achieve their vision.
While estimation provides financial insight into a project, it also provides the project team with a point of reference when it comes to establishing schedules and conducting impact analysis when something needs to change (which is inevitable). As a project manager, a solid process by which we establish an estimate allows me to best serve the client and team.
I would question any firm who claims to offer a high confidence estimate to a prospective client without spending time mapping out the direction an application/product may take on paper. I am not talking about writing a 50 page requirements document (which I once did on a project 10 years before I knew any better). I am talking about getting the “supporting” cast the context they need to provide an informed perspective on the complexity associated with building the application. This complexity spans design, engineering, quality and any other overhead associated with a project.
Let me paint this picture for you. Client X wants to build out a new application. The team to build said application provides client X with an estimate based off of a couple pre-sales meetings. Cost is negotiated until everyone around the table is happy with the economics and then the project is handed over to the project team and they are told to build “this” application in “this” amount of time. Client X is doomed regardless of whether or not that application is handed over in the agreed amount of time. Here’s why:
- The team has no context - Therefore, they are going to spend the first weeks of development getting up to speed as opposed to delivering working features putting the schedule behind right out of the gate
- The team does not “own” the estimate - Someone else provided it on their behalf (who wants to be responsible for something they don’t own?)
- Unexpected risks and complexity will (not “may”) put schedule at risk
- Quality will (not “may”) suffer because the team will attempt to meet the date commitment at the expense of quality
To avoid this at DockYard, we use a tool called Discovery. This is an intensive time-boxed exploration of a client’s business objectives, market and user needs, as well as technological possibilities. These inputs translate into wireframes and those wireframes translate into an estimable breakdown of deliverables that provides a platform to discuss scope, schedule and cost with our client. Our Discovery phase is cross-functional where we have designers and developers working hand in hand to understand the direction a client wants to go. We iterate on design concepts, we discuss technical direction and potential complexities, we map out scope in a way that allows clients to make decisions which may adjust cost and schedule up or down. While this Discovery phase might feel like a tough nut to crack, it typically results in lower overall project cost, higher quality and better probability of staying on budget/schedule.
A recent post by our own Mike Dupuis speaks to the value engineers can add to the “Discovery” phase of a project resulting in savings later in the project lifecycle- Features as Business Objectives
Whether you love them or hate them, estimates are here to stay in a client services context. Therefore, instead of grumbling about them - make sure you’re using estimation as more than just a number but a means to have a conversation. Buyer beware of anyone who slaps an estimate on the table without providing you an explanation of how that estimate was derived.
“Luck is what happens when preparation meets opportunity” - Well said by someone much more insightful than I!
