How to Kill Your SAP SuccessFactors Budget on Day 0

Be Safe - Go for a Fixed Price Project, Right?

If you talk about budget overruns in IT projects to your average procurement specialist or many a sub-average IT director, you'll hear things like "We never have budget overruns, because we do fixed price projects only".

Well, you ignore the evil sniggering of the Big5 Systems Integrator Sales Director in the background and ask one question: "That's great! So, for all of your IT projects, you define a budget before the project and when the project is finished your business users got what they expected and you didn't spend a single Euro above your original budget? That's awesome!"

I have yet to hear a clear "yes" to that second question. If I ever will, I'll probably get onto my knees, kiss the person's feet and ask them to take me on as an unpaid intern to learn their magic. However, what you'll usually get is something starting with "Ah. Of course not! But...". And then there is a long list of budget overruns that are simply not counted as budget overruns, when it comes to the performance bonus of said procurement specialist or IT director:

• "Business never know what they want. So, it's normal that there will be change requests to meet additional requirements. But we stay in budget for the original scope."
• "Some people are never happy. So, no: business users don't necessarily get what they expected, but we always go life somehow."
• "You know how people commit to projects and then they don't have the resources. So, we often have to pay extra because we have to replace internal resources by external ones, but that's not technically a budget overrun, because we also get more resources from our service providers."

By now it's difficult to ignore that Big5 Systems Integrator Sales Director in the background, who is literally rolling on the floor laughing, but the person you are talking to doesn't seem to hear any of it.

Truth is: the goal your procurement team is rewarded for is not always aligned with your business getting the best value for their money spent on IT projects. They like a model, where they can show results of good negotiations and then explain all overruns away. That's best done with fixed price quotes. Much easier for vendors to go in high, sacrifice generous percentages at the altar of procurement and then get it back through change requests.

Waterfall is a Thing of the Past, but Procurement Doesn't Know Yet

Don't get me wrong: as a project manager or in the past as a team lead or company director I absolutely loved fixed price projects. They get me away from comparing rates with offshore providers or competitors, who squeeze the last hour out of their employees to go "low rate + high volume". Fixed prices allow me to totally focus on cost for value - always been my turf much more than negotiating price for unit. However, that does only work for both parties, as long as the deliverable is defined very clearly. Otherwise, winning the contract is often about offering a low initial price for a deliverable that's not going to bring the expected value for the customer - basically a CRM (Change Request Machine). It will only make two people happy in the end: the procurement specialist and that Big5 System Integrator Sales Director.

"So, let's define the exact scope and then there is no problem!". That Big5 System Integrator Sales Director is now gasping for air while trying to suppress his laughter - I'm seriously concerned he might be suffocating before I finish this article...

Fine, but where does this take us? Right back to the old days of waterfall project management, where the requirements were carved in stone in a so called "Business Blueprint", a price tag was attached and then the system was delivered on the basis of that document. It rarely worked: only very rare geniuses can write down, what they need from a complex system, on a white sheet of paper and hit the nail on the head. That's why SAP is proposing an iterative delivery model ("SAP Activate") for SuccessFactors and other cloud solutions. Implementation partners and other vendors use similar methodologies. At the heart is the iterative delivery model. Start with a very lean system based on very high level requirements or a so called "best practice" example and then

1. Discuss with and get feedback from the customer business users
2. Implement the changes
3. Get it reviewed by the business users
4. Repeat

After 2 to 4 iterations of this cycle, you go into final testing and cut over, et voilà: le go-live!

You can still get things wrong on this model. For sure. But you are not set up for failure as with the business-blueprint-based waterfall model.

Fixed Price: a Straight Jacket for Your Iterative Project

The only problem is: how can you define a fix price at the start of the project, if you only develop the requirements step by step?

Unless the vendor builds in lots of constraints and/or a big safety mark-up (a.k.a: a ripp-off), you can't. Simple as that.

At least not in the traditional way. Of course you can agree on some broad guard rails. You can agree on generic deliverable units (e.g. number of calculation rules, data objects,...) without prescribing how they'll be used. You can agree on timelines and number of iterations. You could even go for target costing. I see that nobody wants to embark on a project without a good idea, what it's going to cost. There are ways to get around this without being ripped off. What all of them require: a high level of professionalism, integrity and mutual trust. Here we go again: even in the cold world of B2B, in the end it's always H2H: Human to Human.

I hear someone choking on the word "trust". It's that Big5 System Integrator Sales Director. Otherwise he's gone quiet now.