Business cases for projects make two assumptions that don’t come true automatically: indeed, in most cases, they won’t even come close to being true without a lot of work.
The first of these is “the affected population will all take up almost all the functions required” — in other words, the entire requirement set for the project will turn out to be productive — and the second is that “the requirements as given are right” (meaning optimal for the situation).
In general, neither of these reflects reality — which is why most projects don’t return anything near the ROI forecast for them in the business case.
(The third assumption, that the project will be substantially completed as laid out in the business case — requirements met, on schedule, on budget — has been well-known not to be turn in many cases for so many years that we can, for the moment, leave it aside.)
Change Needs Support: Almost all “IT projects” are laid out, by the business area commissioning them, as ending once the new asset is produced.
This, however, is when opening the business area to change management capabilities and deployment consulting would pay great dividends.
These skills are often found in the cadre known generally as “business analysts” and thus should be drawn from the “broader IT community” to work in the business area.
When a new asset appears, it generally requires process change on the part of the user; it almost certainly also represents an interface change.
Our habits in using computer-related technologies depends on our ability not to have to think about what we’re trying to do.
This is why, for instance, interface changes — say the provisioning of buttons to do frequent tasks — often take years to be fully picked up, if ever: “we don’t see what is in front of our eyes”.
Change management is the skill of helping people become familiar with the new process.
It recognizes that a period of resistance to the change must be worked through (and that those who deny anything much has changed are the ones who will not try to work within the new methods, but instead keep “force-fitting” everything to what they knew how to do.
Learning occurs only after these conclude, then support resources can slowly fade during the integration phase, when normal supervision can take over.
Deployment assistance involves watching and learning what’s working and what isn’t in the delivered system.
Note that this has nothing to do with failures: it is recognizing, for instance, that the interface is cluttered (all those mid-project change requests may play a part in this) and that simplifying it would be a quick and easy update that would make the work come easier.
Easier work increases usage — and productivity. That’s generating return on investment (ROI).
Why Do This? Simply put, a full analysis of an organization’s performance on IT investments will likely show that it is the single-digit ROIs of infrastructure replacement that have actually (in real life) outperformed the planned 20%+ ROIs of the business projects.
Much of this is due to poor integration of the change after systems implementation.
It is an easy and cheap investment of human brainpower to achieve the results that were planned.
The organisation, at the end of the day, receives the planned results much closer to when they were planned to appear.
Everyone benefits as a result.