In the past three posts we’ve explored a structured method of persuasion that the commercial side of business uses to close deals, and seen how surprisingly closely it matches the established architectural technique of creating motivation models. However, while theory is useful, implementation is what counts. So in the last two posts I’m going to apply the technique to a couple of real life examples – names removed to protect the innocent.
Summary: we explore how to use a motivation model to craft the message to different stakeholders, for a sample organization. This organization is the IT department of a bank, that has been spun off to become a profit center, and which as a result needs to become more agile and deliver more resilient services.
We just stated the Situation – it’s an internal IT department that’s been spun off and now has to compete with other organizations, and now itself as a profit center. This situation helps drive the reason why the problems that the bank is facing are genuine problems; the context.
There are two main problems that the bank is facing right now – first of all, new initiatives take too long to roll out because the necessary IT changes take too long. Second, the bank is seeing far too many high priority incidents. To identify which drivers these problem impact, I have gone to COBIT 5. COBIT 5 identifies a total of 17 drivers as part of its goals cascade. The interested reader can download a free overview of COBIT that details the drivers and the business goals they drive, as well as the IT goals that relate to the business goals that fall out from the drivers.
The problem with initiatives being held up by IT has a direct impact on the driver “Agile responses to a changing business environment”. We can record the assessment (the problem) as ‘IT systems take too long to catch up to business needs’. In this case, we’ll draw out a sub-assessment, which highlights the importance of the assessment – ‘Slow IT responsiveness is harming market position’. This leads us through the goal resulting from the assessment– ‘Systems need to be easier to change’ – to the eventual need: ‘Move to a true services-based architecture’.
The assessment ‘Too many priority 1 and 2 incidents’ actually impacts two different drivers that we can draw from COBIT – ‘Business service continuity and availability’ and ‘Managed business risk’. To add more light on how this assessment impacts the drivers, we can highlight two sub-assessments, ‘Integrations between systems are not resilient’, which relates to the first driver, and ‘Insufficient understanding of dependencies between systems’, which relates to the second.
The assessment ‘Integrations between systems are not resilient’ naturally implies a goal ‘Integrations need to become more resilient’. This derives a need – ‘Migrate to an enterprise-class service bus’.
The second sub-assessment (‘insufficient understanding of dependencies between systems’) also naturally implies a goal: ‘Dependencies need to be better understood’. This derives a need that will fulfil the goal – ‘Formally document flows between systems’.
So, an example of using this model, in front of the CEO, who is most interested in the driver ‘Agile responses to a changing business environment’ –
“We keep hearing complaints from the business about how long IT takes to support new initiatives, and they’re saying that this slowness is actually harming our position in the market. So we need to be able to change our systems faster: a move to a true services-based architecture will enable this.”
It seems obvious once expressed, but being able to craft that glib statement can seem very challenging when given a blank slate. Using this methodology and framework gives a way to craft a punchy statement that expresses the argument clearly and opens a discussion.