Many of my client engagements start with a fixed price or not-to-exceed estimate. And often, as people come to trust us, we’ll work within a specified monthly budget without estimating each individual project or request.
That said, I’ve learned from experience that a few rules must be in place for fixed pricing and not-to-exceed estimates to work. (And, in fact, most of these rules apply whether you’re hiring an outside consultant or trying to get an in house project completed.)
1. Don’t Ask for Estimates for Every Little Thing
Estimation isn’t an art or science. It’s simply an exercise in statistics. As I’ve posted previously, an average report takes around two days to write. At the same time, any given report can take between one and five days. The more reports (or interfaces, or spreadsheets) included in one project, the more “reversion to the mean” will apply and the better the estimate will be. This is one major reason we don’t like estimating initial projects of less than $10 to $20K.
There’s a corollary to this: Once you have an estimate, don’t start asking about individual items within that estimate. Yes, you can look at tasks completed as a percentage of total tasks. You can also look at amount spent as a percentage of total budget. But breaking things down task by task doesn’t accomplish much.
2. Have a Solid Testing Environment
If you don’t have a test environment with up-to-date data, it’s almost impossible to get any kind of ERP or BI project done.
I’ve heard all kinds of excuses: We’ve grown. We’re waiting for new hardware. We have data security issues.
I get it. But if I don’t have access to real data, my team can’t possibly test adequately. As a result, we’ll waste your time when our work doesn’t make sense, and you’ll waste our time when we have to do it over again.
3. Give Your Users Time to Test and Approve
Sticking to a reasonable budget means we need to be efficient. So we want to do every task the minimum number of times. As work gets completed, it needs to be tested and approved in a timely manner. If we deliver a piece of work and it sits for two months, neither of us will have any idea what we talked about when we get back to it.
This point is so important that I’ve been thinking about ways I can put timelines into our statement of work. But ultimately, I’m not sure I’ll go that route. I hate complicating my SOWs, especially when things work just fine most of the time.
You’ll notice I haven’t included “requirements and specifications” in this list. In the world we work in, we generally find that what people say they want in a document and what they want in their software are NOT the exact same thing. But if we follow the other rules, we can adjust on the fly.