Project Lifestyle

My thoughts on program (test) instance requirements follow two main scenarios.

First case is medium – large rollouts with a high degree of solution commonality. An example would be Financials and/or Procurement implementations where common business processes are externally prescribed to an extent (e.g. fiscal reports) or gives business advantage (e.g. aggregated procurement to generate vendor leverage).

In this case the answer is a six-pack (instances that is, not beer). 1 Production and a constellation of 5 test environments should be enough to get you through quite a number of locations. In one regional instance project we got through 95 locations in 15 countries on a six-pack of instances. Typically the instances might look like this:

Second case is where you have rollouts with any degree of parallelism over multiple sites with a heavy revenue-side footprint. By this I mean supply-chain, planning, manufacturing, CRM or other revenue/customer critical processes. In these cases there may be a very low level of business process commonality of the different locations. Furthermore, attempts to make the processes common may be inappropriate as they are key to competitive advantage. So what do you do in this case? A dozen usually works well enough.

So what are the alternative models?

If, as PM, you take a laissez-faire attitude (or using corpspeak: use an emergent strategy for instance requirements) you will get instance proliferation. Simply stated you will get more instances than is good for you.

Take my work for it; once you get above 20 project instances you will have no clue what you have or where it is. Configuration management and validation of the holy trinity of setups, patches and customizations across the instances will become a nightmare.

Proliferation of test environments also costs a lot of money. Work out what each test instance costs you (or your customer) to provision and do the math. One estimate I made with a customer came out at US$150,000.00 per test environment. This number included server/disk infrastructure plus support costs on very cheap, high-performance gear. It all adds up.

So it is easier to keep it tight and provision new instances grudgingly – and charge for them!

The six-pack/dozen model is a good starting point if only because it is easy to remember.

Make instance planning a regular element of your weekly program/project review meeting. Inevitably there will be a lot of negotiation and horse trading around clone schedules with project teams needing refresh dates that conflict with other teams using the same instance. All part of the fun. The key element is that the negotiation becomes part of a generally accepted process that all of the teams buy into. Sometimes they will get their way, sometimes they will have to compromise. I see the PM’s job as helping all of the project teams feel that, in general, their needs are being met and that they can roll the program out without (too much)  undue delay waiting for other teams who are playing in the same instance.

This post concludes the initial series of Global Single Instance architecture strategy posts. Further material on this subject will appear on an occasional basis going forward.