510 words. Updated 11 May 2024.

One important element of Enterprise Risk Management is risk assessment applied to technology projects.

IT project failure
Information Technology (IT) projects commonly under-deliver or fail, whether, say, a document management system; CRM (customer relationship management); ERP (enterprise resource planning); Internet of Things (IoT); or virtually any other type of technological change.

What surprises me is that the principles of successful IT implementation do not seem to be widely known, although they have been established for many years. [1]

Risk criteria for tech projects
Just two of the risk criteria to consider when conducting risk identification for an IT project are: 1. poor alignment of goals between the tech initiative and the business; and 2. vague scope definition (scope creep).

Both challenges stem from the client neglecting to adequately define system requirements. Why does this happen? Simply because clients do not understand their own existing (legacy) systems.

To prevent falling willy-nilly into a hugely expensive and ineffective IT procurement, the initial goal for the client is to gain a profound understanding of the legacy business process. Do this before discussions with potential vendors. Admittedly, this is not easy, because legacy systems tend to evolve over time into something rather complicated and inefficient. But the client must be able to answer authoritatively at that crucial moment when the prospective vendor asks: “What is your business process?”

Risk mitigation when planning for new technology
Take the time to map out the following using a flow chart:

a. existing business process, with all the inputs, outputs, steps and transitions spelled out;
b. include all elements whether currently automated or manual; define the quality criteria of inputs and outputs;
c. highlight where there seems to be duplication, waste or uncontrolled variability.

These steps are quite a lot of work up front for the client. But you will find it is gratifying to understand well the current operation and detect its inefficiencies (before the vendor does). The elements of the business process that are idiosyncratic, possibly involving the unique competitive advantage of the firm, also come to light.

Requirements gathering session
This preliminary work prepares the client to evaluate vendor-proposed solutions, and to discuss many things on an equal footing at the Joint Application Design (JAD) or Requirements Gathering session, as follows:

a. elements that should be automated, and which cannot or should not;
b. functions the tech application can fulfil off-the-shelf;
c. where data cleansing, migration, and interoperable systems are needed;
d. unique software features that might be introduced to advantage;
e. where industry-standard functions are lacking;
f. what the client simply doesn’t need;
g. where a custom solution will be required.

Conclusion
The temptation is to think, “The vendor and the new technology will sort out the whole thing for me.”

No, that approach leads to what is later perceived to be an inadequate or inappropriate system, seemingly "imposed" by the vendor. Actually it was uncritically accepted, only because no one had taken the time to deeply understand the business need. And in that case you will end up being another failure statistic in the vast world of IT systems implementation.

Doing in advance the work I recommend will mitigate two critical risks: you will achieve clarity in goals, and prevent scope creep.

NOTES
[1] Innovation - successful tech implementation audio post on my LinkedIn channel.