Many studies have found that an alarming number of IT projects have significant overruns in cost and time—if they don’t fail entirely. In one Oxford/McKinsey study, one in six were outright disasters with costs coming in at 200% of the initial estimates and a 70% schedule overrun.
At Appiphony, we do almost all of our work building Salesforce apps on a fixed-bid basis, so you can imagine how critical it is for us to estimate our work accurately. We’ve found the key to landing on time is implementing well-understood solutions at a realistic velocity. That may sound banal, but since the Salesforce platform continues to evolve, there are always new solution patterns to master.
Good Estimates Are Found Uphill
Once the goals or targets have been articulated, the team can begin testing solution ideas by building proof-of-concept prototypes to put the idea through its paces. (Does it cover all the needs? How does it scale? What trade-offs or downsides are involved?)
What’s frustrating about this phase is that another problem or side effect can be discovered at any time, causing the team to “slide back downhill” either part of the way or all the way. Worst case scenario, the engineers are banging their heads against the wall with no solutions in sight. This is exceedingly rare for us, though: after 10+ years of building Salesforce apps, we have a strong sense of what’s possible.
Most times, we prove out a given solution in a few days and move on. If it appears to be reusable, we have an explicit process to hand the newly discovered solution to a dedicated team (with its own product manager) to create a reusable asset for our Strike toolset.
When all the underlying problems are solved, the team experiences a sense of relief. The trudging uphill is over and it’s all downhill from there. There’s still work ahead—as Morpheus said, there’s a difference between knowing the path and walking the path—but it’s straightforward, manageable, predictable effort.
You Know What Happens When You Assume
This is where we’ve seen our competition get into trouble. It’s easy to say “No problemo!” in the sales cycle and end up with cost overruns and schedule delays. All those studies can’t be wrong. We’d rather ask our engineers to show us the money (in the form of a working prototype) than ask our clients for change orders.