Jon On Tech

We’ve been through too much tough times that they never shared.
They’ve had nothing to say to us before,
Now all of a sudden it’s as if they’ve always cared.
All we need is honesty, a little humility and trust.
Oh, darlin’, can we keep it between us?
- LET’S KEEP IT BETWEEN US

Janus Boye just posted blog about SITATM: When system integrators take all the money. I work for an SI, so should I be horrified by these accusations? Not at all. I think nearly everything he says is true, and I urge you to read his article before carrying on with this one. I would say that most SI’s do not try to take the money and run. We need long term accounts and repeat business to survive.

I do disagree with his final symptom:

You’ve worked with the same system integrator for a very long time on many different projects involving many different vendors and technologies.

In my experience this is, more often than not, a positive thing. Sure, you need to continually re-evaluate all your supplier relationships and not be complacent, but a long history is normally a healthy sign, not a worrying one.

But there are other worrying signs, some of which are also fairly clear to the SI. Here are some more you should watch out for:

• People stop questioning fundamental decisions that were made earlier in the project for fear of the answer. If the customer stakeholder that selected the SI is the same one that will look foolish if they get rid of them, things can spiral out of control. Or, as MacBeth once said to the wife: “I am in blood stepped in so far that, should I wade no more, returning were as tedious as go o’er.”
• Certain features or deliverables are created/demanded simply because they were part of a Statement of Work that is extremely old. Everyone knows the deliverable is useless and will never be used, but the contract is the contract …
• You look at your implementation one day and realise that slowly but surely the CMS product that you’ve bought has been replaced by custom modules until there is nothing recognisable left.
• The excellent team the SI gave you in the pitch and the initial project phases have been slowly replaced by a more junior, less passionate team that doesn’t know your account very well.

And some more suggestions to customers for avoiding SITATM:

• Don’t ask for a fix price for a big monolithic project. If you need a fixed price to secure budget, get one for a smaller, more predictable phase and ask for indicative costs for future phases. Make sure each phases does have useful, tangible deliverables. Reserve the right to use any outputs of Phase X as part of a new SI selection process for Phase X+1. Even if you never do it, it should keep the SI on their toes.
• After working with your selected SI for a Fixed Price project or two, ask yourself if you would trust them on an Agile/Variable Scope basis, or a Time and Materials basis. If the answer is no, you might have the wrong SI. I firmly believe everyone gets better value from a more agile/T&M based approach. But the customer and partner need to first earn one another’s trust – it is a two way thing.
• Don’t be afraid to admit earlier decisions were wrong. As you learn more about the project, you become more informed. Question everything, all the way. Show me a project that got everything right in the initial requirements, and I’ll show you a project team with their head buried in the sand.
• Ensure you have the budget for the support, maintenance and ongoing development of a project. If the budget for the initial launch is massive and then enormously scaled down, it is only reasonable for the SI to scale down accordingly. As a wise colleague of mine recently said, “The real success of a project is determined by the ease of delivering Phase 2″.

Many SI people would argue we should write a “How Do You Know When You’ve Picked A Bad Customer” article. It isn’t uncommon to hear vendors, agencies and sytems integrators saying “X is a nightmare customer. We’ve lost a fortune on that account“. I don’t buy this. I believe there is no such thing as a bad customer. But that’s a story for another blog post.