Pure technical projects can miss millions of benefits unnecessarily. All projects should be organizational change projects led by the business..



The organization had a chronic operational risk in its core system. The technology was dying and the technologists that supported the technology were retiring. 

Technical Change

The new CIO obtained agreement to undertake a technology replacement project – an invisible replacement. In other words. The new system would look and operate exactly like the old one. The project was off and running.

The work streams of the project were…

  1. Infrastructure management stream
  2. (Technical) Quality management stream
  3. Information management stream
  4. Systems management stream
  5. Project management stream

Mutating to an Organizational change

Then a new general manager joined the organization and asked:

“Why are we spending all of this money but not getting any value other than risk reduction?”

The opportunities to bring in new products, to reduce operational workload and costs and make the organization more competitive were being ignored.

The management team agreed to refocus the project and take advantage of the new business opportunities. This made the project more complex in one way (more streams of work) and simpler in another way (less systems work to redesign the new system to look just like the old one).

This project refocusing more than doubled the number of work streams to now include work streams for …

  1. Business value delivery management 
  2. Change delivery management 
  3. Stakeholder management 
  4. Communications management 
  5. Management information and reporting 
  6. Transition and training management 

NB Some of these streams may have been added to the technical project late in the day to enable ‘implementation’, but they would have been viewed and treated as support streams only.

The beneficial consequences

The project costs increased, but the business benefits went through the roof! Millions in benefits that would have been foregone with the technical-only approach were not identified and quantified.

A good 'technical idea' was found to be a bad business investment. Not only were the business benefits missed, the organization would have been (expensively) locked into the past way of thinking and operating.

What was interesting was that because the project suddenly transformed from a purely behind-the-scenes technology project, with no business involvement, into a business driven project, the fact that the project was now a ‘change project’ was seen as natural. The whole focus was now on:

“How are we going to change the business?”

As a result, the business wanted to get involved and lead the change.

The original version of the project may have "succeeded", but it would have locked the organization into the past at considerable cost. It would have also psychologically made the IT department resistant to future changes as they had just devised and worked so hard on locking in the past. The ability of the business to subsequently improve would have been severely curtailed.

The second version of the project did succeed - but not as much as it would have done if business improvement had been the initial driving force of the project.

The end of 'technical projects'?

We often hear:

“There are no such things as technology projects”.

Well - there still are but shouldn't be, as this case example illustrates.

If you are going to exchange technologies without looking for business improvement opportunities, you are shortchanging your organization of the opportunities unknowingly being foregone.

In Conclusion

Please don’t think of this as an isolated example – I could have cited many; some of which made it to the end, delivered the new technology only find it obsoleted by business changes they had ignored. Some of these purely technical projects were re-evaluated to find tens of millions of dollars of available business benefits foregone due to the technical myopia.

Let us make a commitment never to have a technical/technologically driven project again.

Every project must be business driven and visibly contribute to the strategy. This sounds obvious, but even this simple test is too often failed.

Topics: Change Management, Benefits Management, Program / Project delivery

Further Reading

 




Footnotes

[1] ...





Revision History

First published: Simms, J. (Jan 2013) as "Should You Aim For A Technical Or Organizational Change?"

Updated: Chapman, A. (March 2020), Revisions and Corrections