How much will it cost?
Invariably that’s the first question most of us would ask when making a purchase. When buying a product, be it a Taskmaster client license, server hardware, a toaster oven or a jar of peanut butter, the answer is usually pretty straightforward. When it comes to professional services however, the answer more often than not begins with a single, agita-inducing, eye-rolling response:
“It depends.”
A lot of this has to do with the inherently amorphous nature of professional services, particular in the arena of large-scale enterprise software. Professional services is the process of transforming your software or product into a flesh-and-blood business solution. It involves refining the functionality, softening the corners, and honing the edges to fit the nuances, nooks and crannies of your particular business. Understanding the level of effort involved necessarily entails learning key details about your requirements.
At Datacap, as with most organizations that produce enterprise software, there are a myriad of questions that first need answering before offering even the broadest of price estimates. How many types of documents? How many fields? How many workflows, and how complex? With what other systems will it need to integrate, and how open are they (is there a published API)? What is the average and peak throughput? How will errors and exceptions be handled?
Therein lies the ugly truth for professional services organization: the reality is that there’s a significant amount of work involved before we can know with any degree of certainty just how much work will be involved. In fact, we don’t really know exactly how much work is involved until we’ve completed the most difficult (and important) phase of the project… the thinking part, or what we call the design phase.
In some industries doing most or all of the work in pre-sales is a commonly accepted practice. Advertising agencies, for example, when “pitching” a potential account will expend huge amounts of internal resources to brand a product or create a campaign (“Purina cat chow… chow Chow CHOW!”). Not surprisingly, providing technology services to these industries tend to be most problematic. And there are a million reasons for this, ranging from market conditions to complexity of implementation, enterprise software and professional services very rarely work that way.
One solution for particularly large or complex implementations is making the discovery process a separate pre-engagement, with the final deliverable being the design document. This design document outlines the complete technical solution, including all business processes, touch points with external applications, use cases, and answers to any other technical or business challenges posed by the project. In short, the design document is the complete how-to guide to implementing document capture, the blueprint and roadmap to get you from where you are now to exactly where you want to be at the end of the journey (and, like Google Directions, it will estimate how long it will take to get you there).
This is a billable service, although typically the solutions provider may discount it against the actual implementation. This can have the unintended side effect of changing the question from:
“How much will it cost?”
to:
“Why do I need to pay to find out how much it will cost?”
The answer is you aren’t paying to find out how much it is going to cost, you’re paying to define and document exactly what you want to do, and how you are going to accomplish it technically. A good design document can stand on its own and should be vendor-independent; the output from this discovery phase, the design document, should be implementable by any solution provider. The design document is your insurance that whoever you choose for professional services will implement exactly what you want (and only what you want). Any “gray” area, any processes or logic that isn’t fully defined, will be left to interpretation by the integrator; the decision they make will almost certainly be less informed than your instructions, as no one knows your business better than you do.
In the next installment, I’ll examine the role of the Statement Of Work (SOW).
