“Your goal is to set up the conditions for success.”
At BP3 our teams go in and rescue a lot of BPM projects that previously failed to get off the ground with the big generalist consulting firms. I thought a quick post explaining why these failures happen and why we don’t fall into the same trap might be useful here. Let’s start with what we observe in these customers’ projects.
- Incredibly detailed specifications for the software, regardless of the native capabilities of the underlying software platforms.
- Named resources (staff) on the project, in the contract
- 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.
- 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.
In addition, at the moment we arrive we see:
- 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.
- 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.
- 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.
- 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.
- There is no path to the finish line or success.
The basic problem is that you can’t legislate competency. 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.
So in comes BP3. Why are we any different?
- Our contract doesn’t attempt to legislate requirements. 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.
- 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.
- We focus on the conditions for success – and when we don’t see them we fight like hell to achieve those conditions. Conditions don’t guarantee success – but the wrong conditions can guarantee failure. So we fight to get those conditions right and allow our implementation teams to focus and do their jobs delivering.
- We don’t allow people to sit around or write bad code and stay on our teams. We understand that success is binary. And someone who isn’t competent doesn’t just “not help as much” – they literally destroy value on your project: distracting your best people, contributing code that has to be rewritten (only after triggering bugs and test failures, and after investigating debugging and rewriting).
- We aren’t confused that an hour of labor is an output. An hour of labor is an input to your process – meaning not all hours are the same. Each person’s hour of labor is different from another person’s. You want the best inputs you can get in labor, just as you would if you were buying clothes and choosing fabric. A bad seamstress doesn’t just sew more slowly, they literally ruin the fabric they are sewing – wasting fabric, money, and time.
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.
The difference in price in the United States (or any market) between the very best BPM implementers and the very worst is not very large. Even if you include offshore, the delta between the best and the worst is maybe a factor of 2. But the delta in terms of productivity and value is easily more than 10x. Partly because the worst implementers (typically generalist consulting and IT firms) are actually destroying value – negative value- rather than producing value slowly and with more effort. This is why it generally pays to just get the best people and knock your BPM project out of the park.
When you have a great vendor like BP3 working with you – 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. Legislating competency in to your contract with a great vendor like BP3 is equivalent to the Lean concept of overproduction. Too much effort into something that doesn’t require it.