The trap of IT focused change

Sometimes we forget what the essence is of business change.

Picture an example situation: a business understands that they want to improve their customer relation processes. Several painpoints were found - complaints were lost, addresses of customers incorrect, wrong shipments, whatever. The company understands something must be done, and since data plays a big role, a project is started with a large IT component (and sometimes even a "communication plan" is included).
During the project a lot of effort is spent on the IT part. But, during the project the projectmanager of the IT part starts encountering various issues that he of she can not solve, and does not see as part of the scope. It's the " fluffy" stuff around business change - responsibilities in the to-be organisation, training, the full process, process management of the new CRM department, hiring people, etc etc. The issues get signaled (if we are lucky) to the steering group, but most of them are not picked up and acted upon. In the end the IT project delivers, stuff is installed, and hell appears: confusion, frustrated users, boycots, desperate management, and the easy one to blame: the PM.....

Hm....

In the Netherlands we have a nice Dutch abbreviation that businesses are more and more using:
It's called COPAFITHJ. In essence it's a list of factors that you need to cover as a project/program, when dealing with change. It tries to make us clear that when changing a business IT is only one factor, and that time/effort/money/people will need to be directed to the other factors as well, to make a change succesful.

COPFITHJ stands for:
- Commercial: will our change effect our commercial position (products/services/markets, customer relations)?
- Organisation: will our change effect the structure in which people work, in terms of home base, power, communitity, management?
- People: will the change impact people, in terms of their role, communication, relations, work, responsibilities, required level of expertise/required training & coaching
- Administration, will the change impact required handling and storage of information, including reporting, etc
- Finance, will the change impact current and future budgets, allocation of budgets etc?
- Information, will the change impact the information we require and produce, to perform our work, answer questions and allow the management to steer our work?
- Technology, will the change impact the technology we have in our business? Software, hardware/infrastructure
- "Huisvesting" - Worklocation, will the change effect the psysical location we work at?
- "Juridisch" - "Legal", will the change impact our legal situation.

Is it a great abbreviation? I don't know. But I am glad I can use it to make people aware that change is something bigger than just IT. Too often I still see projects where on the basis of some vague improvement needed by management, some SME's and IT people start running the IT game (requirements, design, build, test), and sometime along the project the "Fluff" start hitting in, gets lost or given too little attention, and we end up with a mess...

The key lesson: approach your business challanges in a holistic way, and do this right from the start until the end. Do not think that IT change will magically result in change in the other dimensions. Focus on the complete business context.

As a sidenote: I am glad that BPM is getting more and more attention. It means that at least the P in the above abbrevation is getting more attention!

My rule of projectmanagement: smaller and deeper

December is for me a time to look back on the year and see what I've encountered and learned.

One observation keeps coming back every year, based on the IT projects I have done so far:

I call it the "It always gets smaller, but deeper" rule on projectmanagement.

This is the essence:



In a typical start of a project, your planned scope will look something like this:

But, after working hard and delivering results, slowly the team starts to realize that finally the scope will turn out like this:

The patterns in play:
- At the start we are optimistic, want to please the customer, maximize the business case value, but are unaware of the complexity of some of the requested features/requirements

- Optimistic planning does not cover all kinds of time-loss on inefficiencies and unplanned ubut needed activities

- During the course of the project, more and more insight develops (the "ouch, does this feature mean this/require this...." moments).

- Time pressure starts growing.... discussions on scope grow. The projectmanager will, depending on sr. level try to hide this or create an early and open discussion with the client

- Negotiations are done. Functionality is prioritized (again) - often succesful, because the client was not aware of the complexity either!

- And stuff is delivered (or another smaller but deeper iteration is started ;-))

Be aware....