UBERR vs. CAB’s - The new era of Risk & Change Management - Matthew Hooper VigilantGuy Digital Transformentalist - Create High Performing IT

CAB’s suck, and I didn’t spell UBERR wrong.

I’m talking about Change Advisory Boards & User Based Enterprise Risk and Release. (Yeah I made that up, but it makes for a better blog, so bear with me.)

I do want to make a comparison of Cab’s vs. Uber.  Uber disrupted the car service marketplace with a digital strategy.

CAB’s (Change Advisory Boards) have disrupted IT services with a physical strategy… and not in a good way.

Why were CAB’s put in place and what benefit have they brought?

Organizations of low maturity experienced symptoms of organizational dysfunction. Change across the IT infrastructure were not effectively being orchestrated.  Unplanned outages, failed releases and critical business impacts required much more stringent governance to be put in place to control the “chaos”.  Strict policies of change control required that all changes would now be reviewed by a steering committee that would sign-off on change activities to ensure coordination and quality were maintained.  In the short-term, CAB’s provide an apparent marked improvement in order and stability for IT activities.

However, the benefits soon wear off from this reactive stop gap.  The increasing backlog of changes start to have an impact on business capabilities not being achieved.  Bureaucratic processes of risk identification, mitigation, testing and approvals cause meeting power trips and analysis paralysis.  The committee of management that is so far removed from the actual risks, stick to a scheduled standing CAB review meeting where they nauseatingly walk through a large list of requests of which they will only get through the top 20 or 30 before the rest are pushed off till the next meeting.

This massive point of constraint in the flow of IT work starts forcing 3 unwanted outcomes:

  1. IT staff knowing their small changes are not going to make the top 20 start bundling smaller releases into more complex bundles, improving their chances of getting approvals in.  Yet at the same time increasing risk because fault isolate and identification becomes masked.
  2. Lagging requests soon get escalated to emergency releases, bypassing the coordination and scheduling activities that are integrated into communication plans.  These emergency releases now increase risk because validation time is minimized, causing IT to slip back into unplanned work mode.
  3. The business owner of the requested functionality looses patience with IT, and soon starts efforts to acquire the IT capability through other sources; (Shadow IT, Cloud, or BYOX).  Causing additional complexity and burden on the support processes, asset tracking, and funding of capital investments for existing shared services.  (I’m not against Business/Shadow IT, but a proverbial gun to their heads this is not the way to approach a digital strategy with our business partners.)

Uber-vs-black-cab-v4-300x1911-300x191While CAB’s are usually effective at stopping the hemorrhaging of failed IT changes in the short-term. The ultimate solution that IT should be focused on should be efficiency, not control.

UBER, the car service, offers travelers 3 options transitional cab services do not.  In these efficiency gains, they also reduce the risk and complexity associated with traditional taxi services.

1) Digital request & transparency:

A user of UBER does not have to wait in line to hail a car.  They do not need to search or be on the lookout for an empty car.  They do not need to be wasting time waiting, checking if a car has arrived.   The Uber app knows where the user is, distributes the request to the appropriate drivers, and shows the visual location of the driver at any point in time.  Any text messages or communication are also tracked against that request and performed within the app.

2) Digital governance and decision-making:

A user of UBER can see the driver that has accepted the request, their quality score, the type of vehicle they will be using, and the cost of the ride.  At the same time, increased demand will raise the prices, multiple local users will offer the option of shared rides, time and costs are automatically adjusted for desired vehicle class.   Real-time data and tracking gives the users options to make effective decisions.

3) Reduction of physical processing through digital automation:

Actions required:
Uber Cab
Communication about where should the user be picked up
Automated  Manual
Communication about when the driver will arrive Automated Manual
Transferring monies for completion of ride
Automated  Manual
Receipt for ride (In fact mine goes automatically into my expense reports.) Automated  Manual
Historical view of you travel Automated  Manual

If you want Change Management to maintain value as vehicle of effective improvements through coordinated activities, transparency into risk and benefits, and enablement of adherence to compliance, you have to adopt a digital mindset.  This where LeanIT and DevOps are demonstrating value over older methods like ITIL.

The CAB and the CAB review are 100% physical functions.  Every IT system change that goes in front of the CAB for approval was a failure to document the risks, document the benefits and coordinate actions into a system of record.   I’ll say that again, EVERY IT system change that goes in front of a CAB for approval is a failure.

There is a place for the CAB, but it’s focus should be on organizational change, process change, and business scheduling.  My recommendation is the elimination of the PMO, and role that function into Enterprise Architecture (EA) which guides the IT Value steering committee.  Here is where the CAB will add true value keeping EA standards in the forefront of sustainable IT Value.

If you adopt a digital mindset your change process will not operate and be dependent on human review.  Rather, the system of record will process requests based on factors of risk, priority, benefit, availability of resource, schedule of dependent configuration items, schedule of business activities.

High performing IT organizations don’t improve operational agility through prevention of failures, they improve through resiliency of failures.  Software releases, infrastructure changes, patch updates, and other risk activities will be a constant.   IT must plan that changes will fail.  That is why smaller releases and automated configuration changes will utilize methods for updating change records.  The risk factors are managed from the point of initial request all the way through execution of the functional knowledge worker;

i.e. a Network Engineer needs to patch a Network Switch, they manage that initial request, as well as the actual config change through a system of record, that allows them to see conflict, dependency and risk exposure.  The system determines if this can be self-governed or needs more oversight.

This user based risk and release strategy pushes down accountability to those who are closest to the change, where feedback can be evaluated quicker and adjustments or remediation can be made to truly reduce impact on business outcomes from a failed release.

Agile Service Management works more like UBER

1) Digital request & transparency:

Requests are entered through self-service, which immediately starts to analyze requests and provide critical feedback and transparency.  Based on role/department/skill level request options.

For example: An email administrator requesting a change is provided with options appropriate to their role/function.  Asset information is provided based on the context of their request.  Addition of new SMTP server to DNS would require the SMTP assets to be in the CMDB, the DNS servers to be relatable in the CMDB.  The email admin would have to add these CI’s to the change request.  Based on that dependency, the DNS administrator would have to approve the change.  Since DNS hi-jacking is a security concern, a Security Engineer may have to sign-off on the approval.  If monitoring tools need to be updated, that task is then added to the change request at that time.  Teams are encouraged to continue to add information to the change record.  This builds knowledge and insight.

Now a change manager may be able to look through this record and evaluate whether this really requires CAB review.

2) Digital governance and decision-making:

As the record moves through it’s process it is capturing risk, increasing awareness through notes and knowledge, automating approvals, and collecting valuable data to help make real-time decisions.

For example: If that SMTP change is for a business process that affects compliance, it could immediately increases the expected fulfillment date.

The selection of assets affected by the change affects the levels of approvals, or role within the organization of the approval, instead of the Security Engineer, perhaps it now needs the CISO to approve.  The benefits section will also help prioritize the timing of the review.  Instead of waiting for the next CAB, this may warrant a more immediate review.

Again, notes, discussions, detailed instructions, are captured in the system of record, NOT EMAIL or SPREADSHEETS!  Thus building enterprise knowledge that can be used to tweak the systems automation for better routing, evaluation and supporting governance later on.

3) Reduction of physical processing through digital automation:

The new role of an Enterprise Change Manager is to try to find a way to increase collaboration and automation so that every change is a standard pre-approved change.  Improving the processes and systems so that changes are executed at the functional level, with full transparency and awareness.
Actions required:
Modern ITSM Old ITSM
Change requests against approved projects
Automated  Manual
Change requests based on compliance requirements Automated Manual
Conflict in release schedule reconciled Automated  Manual
Notification to appropriate parties of change Automated  Manual
Security, functional and performance testing Automated  Manual
Release of configuration change into production Automated  Manual
Configuration detail data updated based on request Automated  Manual
Monitoring and validation of production quality Automated  Manual
Alert to appropriate teams of impact or failure Automated  Manual
Roll-back of configuration change Automated  Manual
Updates to CMDB of roll-back and failed release Automated  Manual
Historical view of successful/failed changes Automated  Manual

This new role of change management scales.  Which means that with the increased performance and transparency, there is now tremendous value for IT functions and Business IT (Shadow IT) teams to leverage and utilize it.  It allows CAB’s to be more productive and more strategic, giving opportunity for discussions about real business impact analysis.  It opens the opportunity to include Marketing, Sales, Production and other line of business owners or BRM’s into the conversations.  And this time they will actually come, even thought you invited them in the past, none of them want to sit in your boring technical change reviews. Now that those changes are pushed down into the autonomy at a functional level, the conversations can be higher strategic business level.

Part of this digital transformation of Service Management also requires a focus on Asset Management and Release Management.  In my next blog I’ll tackle how ITAM, Software Config and Systems Config management also require systems of records to work at scale.

Written by

Digital Transformentalist Twitter: @VigilantGuy http://twitter.com/vigilantguy Linkedin: http://www.linkedin.com/in/matthewbhooper Web: http://www.vigilantguy.com Matt Hooper is an industry advocate for Service Management strategies and best practices around Enterprise Service Management. For over 20 years Matt has instituted methodologies for business intelligence and optimization. Leveraging technology to drive business outcomes, he has built an industry reputation for his highly effective approach to creating value through Service Management. Matt is active on Social Media known as VigilantGuy, and co-hosts the weekly podcast: Hacking Business Technology. HackBizTech.com

Leave a Reply

Matthew Hooper

Digital Transformentalist