Partner View

The Best Estimate

Even with a well-defined project plan, it's best to let the customer know that an estimate on deliverables is just that -- an estimate.

• By Jeff Rudolph
• June 01, 2006

For a solution provider, an estimate includes a well-defined set of deliverables documented in the proposal and the subsequent requirements document. Ultimately, it represents an educated guess about the project's cost, which is, of course, subject to change as a result of unforeseen challenges or circumstances. Too often, though, customers see an estimate as a bottom line that's set in stone and that includes all the costs of implementing a new system as well as any additional costs that might come up during installation.

Once, in the middle of a three-month ERP implementation, our client landed a new account of its own and needed to begin working with its new customer right away. To comply with that customer's electronic data interchange (EDI) process, our client had to adopt a complex set of rules into its practice. So our implementation team hunkered down, wrote the necessary interface and met our client's tight deadline. As a result, we billed an amount well beyond our original estimate. Our team assumed that the client understood that this extra work hadn't been included in the estimate. However, our client didn't think that adding a new customer should change the project's scope. Eventually, we reached a compromise, but not without some ill will.

Unfortunately, such situations are all too common in ERP implementations. We make money by billing customers for time spent on projects. Unlike other products for sale, hours can't be returned. If we don't get paid for our time, it's gone and can't be sold to someone else. Our implementers want to do the best for their customers, and our customers want to run profitable companies. So how do you balance those positions to manage customer expectations about estimates -- and prevent writing off billable hours?

First, here's what not to do: Don't beg for forgiveness at the end of a project. Ask for permission before it starts by having the customer acknowledge that there might be some cost overruns. If you wait until the end to bring up that issue, your chances of recouping money for extra hours spent are next to nil.

We begin each project with a simple one-page letter of understanding. This document explains how we reached our estimate, noting that it's subject to change as the project moves forward. It also says that all adjustments will be discussed with and approved by the client via a change order before work begins. Both our project managers and the client sign this letter at the outset. We then hold a kick-off meeting with the customer to discuss the project's stages, team members, sign-off documents, change-control process and our status-reporting mechanism -- including the all-important budget report.

That bi-monthly report shows our progress toward project milestones, comparing actual time to estimated time. If it appears that we're exceeding our original estimates, our project manager discusses the situation with the client, and they agree upon a remedy, signing a change order if necessary. Regularly scheduled meetings with the client allow us to discuss new requests and potential problems. Results of all meetings, status reports, change orders and other pertinent project documents are posted to a dedicated SharePoint portal.

Our well-documented processes and procedures, along with our use of SharePoint and a change-order system built into our Navision ERP application, keep project management overhead to a minimum.

And, while we're constantly refining our methodology, we've made great strides in reducing "returned time" and defining "estimate" with its intended meaning.