Archive for IT Service Management
… application of BC skills to BAU
Posted by: | Comments
Since returning from WCDM last month I have began a new engagement with my largest client. This role involves the application of Incident Management and Control Room discipline to the delivery of a major new IT/IS change program.
The program is in the final stage of a 4 year delivery cycle, and rapid response to defects and outages is critical, along with simple (but effective) delivery of ‘intelligence’ to Executive Management.
This is a great example of where people who have developed skills in the BC domain can add value to the day-to-day operation of their business.
If your company/client is not in the business of providing BC services – then BC is not a ‘core’ focus area for your company. You may argue that it should be, but it rarely is. Simply providing governance and oversight is rarely the core business of anybody, yet it seems to be the primary focus of many in this field today.
Not surprising then that we often do not get any respect – as John Glenn commented on his blog recently.
I expect the central BC folks in any company to be skilled at Command Post/Control Room disciplines. In particular they need to be able to contribute to the Planning/Intelligence capability in a significant way.
It is a myth that the BC folks will run the company in a crisis. At the other extreme of popular BC-culture is the idea that you go and play golf in crisis (no role in the recovery). Those who believe the myth are self-deluded, those who follow the later view make themselves irrelevant to their company.
If you dont have these Incident Management/Crisis Management skills and capability in your BC group – go and develop them. It is a first step to making your BCM Program relevant to your Executive.
There is another aspect we need to recognise if we want to become relevant. As I noted above, the vast majority of companies are not in the BC business. So unless you have some other skills and knowledge (other than claiming specialist BC expertise) you may struggle to become relevant.
BC folks are well positioned to understand all areas of the business. But knowing who to send templates to and collect reports from just wont cut it. You will need to know what they do, why it is important and, to some extent, how they do it. Then you can contribute a little more to the BAU process.
We need to develop wider management and leadership skills to really take a position of relevance. Diversification, an essential aspect of your own skill set.
We also need to take a stand about the number of people with no practical, real-world skills but holding “BC Certification” (because they can recite the text book) who are appearing everywhere and adding little to the relevance of BC to the business.
What are you doing to make your BC Program relevant to your organisation?
Links
Photo Credit – the control room at Alcatraz. I have a more modern typewriter in mine.
John Glenn – on the Rodney Dangerfield profession
… Brown is the new Green!
Posted by: | Comments
I don’t know about you, but I cannot remember the last time I got to work a “Greenfields” client. What a shame then that so many people still treat all situations as being greenfield.
Sometimes you can find that there is no real BCM Program in place, but generally there is some form of “tick in the box” BC Plan on a shelf somewhere.
Irregardless of this, it is very rare to find an entity that does not have a sunk investment in IT, and perhaps some form of DR in place. Even if it is just a backup tape the IT guy takes home each night.
Brownfields IT will probably contain infrastructure, applications and perhaps SOA services that have not been designed to facilitate failure nor designed for recovery.
The real bottom line here is that in this situation the Recovery Time Objective (RTO) is not always going to be derived from any analysis of business needs, but from the “as built” IT DR solution. Sure an Enterprise Business Impact Analysis may provide the input for a business case for future DR investment, and after that investment has been made and commissioned the new DR Plan can work to a new RTO.
Until then your business users better have manual workarounds to cover the difference between the time they would like to be without systems and the time they are going to be without them.
Shocked? Heresy? No, supported by a best practice guide …
- “A RTO represents the required level of capability that the organisation aims to recover within a defined time frame. This is often determined by the ‘provider’ of the infrastructure or service.” •
- Standards Australia, HB 292-2006, p64
Do you know what the “as built” recovery of your IT systems is?
Do you have “fantasy” plans that are not related to real, proven recovery capability?