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.
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.
This massive point of constraint in the flow of IT work starts forcing 3 unwanted outcomes:
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.
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.
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.
Communication about where should the user be picked up
|Communication about when the driver will arrive||Automated||Manual|
Transferring monies for completion of ride
|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
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.
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.
|Modern ITSM||Old ITSM|
Change requests against approved projects
|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.