Chocolate or Vanilla

The more likely scenario is that the project is being promoted by one or two groups within the organization, who feel a burning need for it, and a much larger number of people who feel they will be affected by the deployment, and want to get their requests for functionality or control into the project before early on. This makes deploying a “vanilla” install or a default system less desirable in their eyes.

The clues that this is what we will be facing often come early. A Request for Proposal (RFP) arrives and, as we dissect it to try to determine what the client really needs, we find lists of functionality that don’t seem to have any consistency. There are similar or identical functions listed more than once, but written in a different language each time. There are requests for functionality that are diametrically opposed. (e.g. “All data in the system must be completely centralized.” and “The system must allow for data to be autonomously managed in a decentralized fashion”) When we see this sort of thing we know how the RFP was created: By committee!

For those who may never have suffered through this kind of exercise, you can only imagine how tough it is for the person heading the committee. They have probably been with the project since the early days and are committed to see the new enterprise system deployed within the organization. When the project started it was a small group of like-minded people but, as the project progressed, more and more divergent points of view arrived. Just to construct the RFP, numerous points of view now had to be represented – and this is the document that is sent out to happy contractors like ourselves!

When we arrive to do the work, this can be a tremendous challenge. First, we have several perspectives to satisfy before the project can be declared complete. If we’re doing a timesheet system, we may have the project management department, the payroll department, the HR department, the IT department and senior management, all lobbying for their particular interests. What if some of these interests are in conflict?

So, we start from the vanilla perspective. What would this system look like if it were installed as delivered? The publisher, after all, has likely spent a fair amount of time making sure the system has some usefulness from the moment it’s installed.

This is the baseline install. The closer we can keep to this baseline, the easier it will be to do upgrades, create training material and generally, to deploy the product. The more “vanilla” it is, the more materials we’ll find from more suppliers that can help with training, configuring, third party assistance, and more. The more we customize what we’re working on, the closer it will get to the vision of each of the interested parties. It’s a series of trade-offs that have to be negotiated.

It’s easy to see the result when the implementation goes too close to one extreme or the other. If you go to close to the default install and your users are unlikely to adopt. The system may not be close enough to what’s familiar. If you go too much on the customized side, the system may never deploy. The further you get from the default install, the more effort is required just to get the system functional. Moreover, when you then turn to the publisher for assistance, they’re handcuffed. The system gets to be so far away from the baseline that the technical support people are hard-pressed to know how to answer any questions on it.

So, how far along the flavored path should you travel away from the baseline vanilla?

You can start the conversation at either end and work towards the middle. For an organization that is interested in long-term deployments, the best place to start is at the highly flavored end of the conversation. You’ll find plenty of people in this corner convinced that their way is the best way, and only want to hear how you’ll do it their way. In the ultimate scenario, you’ll be able to place numerous programmers for an extended amount of time to write the perfectly matched EPM or Enterprise timesheet system.

At our firm, what we train our technical people to do is to start at the other end; from the vanilla end of the scale. We start with a default system and then look to justification for each change. We let the client and each faction know that we’re prepared to adapt to anything they require, so that we don’t generate resistance on the first day, but every change needs to have some business purpose. Note that I didn’t say some “functional design”. No, it’s got to serve a business purpose. So, when a future user says “I need a dashboard that shows this data color coded by age”, we ask “What business decision will you be able to make or be able to make easier if you had that?” Often the reply is “We’ve always done things that way” which is not, of course, a good business reason.

A couple of years ago during an EPM configuration, I was presented with a collection of reports and told that the client expected all these reports to be represented in the new system. It was an intimidating list of 212 reports and I’m sure just collecting the report samples must have been a significant task. I looked at the several inch thick pile of paper samples with some dismay imagining the weeks it was going to take us to recreate them all.

My response to the client was this, “We’ll be delighted to do these reports for you. But, first, would you please arrange it so I can speak to the readers of these reports to determine what business purpose they’re used for.”

Needless to say, finding such people was a challenge.

In the end, we did only 12 of the 212 reports. We couldn’t find an audience for the rest. ‘Why were there 212 report samples then?’ you ask. ‘It’s the way it’s always been done and the way we want to do it forever,’ is the answer.