Scott Francis wrote a great post that very much resonates to our experience.

BPM projects are special because business processes are volatile by their nature. They are changing because (1) the business environment is ever changing and (2) our own understanding of what is the best way to do our job and to serve our customers is changing.

It happens all the time: as soon as the customer’s process is discovered and mapped, people at the customer side say: “do we really work this way?!” Meaning that it’s so obviously inefficient and ineffective. Yet it only becomes obvious after the analysis is done by a competent process team, not in advance.

This is why an attempt to do the process work traditional way - on the basis of rigid specifications and contract terms - is doomed. Here is how Scott describes it:

1. Incredibly detailed specifications for the software, regardless of the native capabilities of the underlying software platforms.
2. Named resources (staff) on the project, in the contract.
3. The contract includes most or all of the specifications, binding the vendor to an exact implementation definition, and removing all doubt about what is desired.
4. Having secured very rigorous contracts, with performance penalties and exacting specifications, the contract will also specify an extremely aggressive average rate for the personnel on the project.

Big generalist consulting firms tend to accept these terms, typically resulting in:

1. Sloppy code written to create a UI that minimally meets the specified result in the contract, without any of the hidden requirements of code quality and maintainability and structure and commenting being met.
2. An inability for anyone at the vendor to stand up and tell the customer that the requirements are wrong, and that we should change course. They don’t have the gravitas and the experience to even know that they can and should do this.  And their management chain will tell them not to rock the boat – deliver the contract.
3. Several people literally sitting around doing nothing productive at all. They’re writing code that someone else will have to remove from the project because it isn’t meeting any requirements and is only introducing the possibility of bugs.  It would be better if they were surfing Facebook than writing your code.
4. That low average rate is really a very high rate for one person to write good code and for several others to overwhelm the good code with bad code and regression errors and manual testing.
5. There is no path to the finish line or success.

Now what is the alternative?

We assume that whatever requirements have been written are either: wrong, out-of-date, imprecise, ambiguous, unrealistic, incomplete, incorrectly prioritized, or all of the above.  We assume this because it is true, 100% of the time. The only way to get requirements correct is to build the software and let users experience it and provide feedback.

Experienced BPM team typically needs about 5 iterations to develop a viable process model and usable process application. If either customer or provider is unexperience, double this figure. The initial and resulting views of the process differ like night and day

We have the courage, experience, and edge to stand up and tell a customer when we think the project is off-track.  This is *why* our customers pay our consulting fees. Not just to write the code, but to be their advisers and partners in success.

I call it “Consultant’s Dilemma”:

• to do what the customer asks for, which isn’t what he really needs, in most cases, or
• to argue and to accept the risk that customer won’t like your objections or rather that you dare to have objections

More words of wisdom from Scott:

You can put whatever you want into the contract – and you may feel better in the end that you get some or all of your money back, or if you can sue the vendor into oblivion.  But your goal as an organization isn’t to plan for failure!  Your goal is to set up the conditions for success.

We may spend together several months to create detailed and valid specifications but the amount of time and money spent would be close to those needed to develop an executable prototype of the process application.

Finally, you can’t legislate competency.  If you’re getting the best rates for coders, you’re probably paying the most you could possibly pay for your software – in failures, blown production deployments, and legal fees… legislating competency into your contract is  a waste of time -  a waste of vendor management and legal resources – and may actually increase the odds of failure rather than decrease the odds, because the contract will bind us to bad requirements.

It’s well known that “unhappy customer produces unhappy developer.” Yet the reverse is also true: cut the contract to the point where provider aren’t much interested on the financial terms and they will think more about cutting their costs than about product quality and ultimate business result for the customer.