The BIA and a mid-process restructuring

Life evolves.   As does business.   And corporate structures.   And therein lies a challenge for Business Continuity.   How many of you have almost completed a phase of the continuity program when the groups you have been working with abruptly undergo a restructuring thus requiring a lot of rework?    While the constant change and evolution of corporate structures can be one of the more frustrating aspects of our field it is also, for me at least, one of the things which keeps life interesting.    That said, corporate reorganisations and mission changes can play havoc with our project timelines and delivery schedules.    It is, perhaps, ironical that the very people who plan for operational disruptions should be so susceptible to them in their own work but such is life.   In my last few blog posts, I’ve been focussing on BIA-related issues and will continue to do so in this post

While there is usually very little we can do to affect the changes, I do believe there are things we can and should do to minimise the effects of those changes.   In some ways, the BIA phase may be the BCM phase which can most easily respond to a restructuring.   When completing a BIA, I prefer to focus on the smallest business unit (BU) which makes sense.   In some cases, this may be a department, in others a team within a department.   The point is to capture the information for a group of related business processes which generally work closely together towards uniquely identifiable ends.   Using this approach leads to a level of modularity which can give the BIA a level of resilience to organisational change.   (I also find that it makes it a lot easier to get the relevant people into the same meeting.   It also keeps the group small enough that everyone can contribute and remain engaged in the process.)

In the simplest restructuring, an entire BU is migrated into a new reporting structure while leaving the BU’s activities and personnel untouched.  In this case, if one has a BIA focussing on the BU, adapting to the change may be as simple as changing the reporting lines.   If this is the case, be grateful!

The other end of the spectrum is when multiple BUs are broken apart and merged into new structures with new objectives.   In this case, your options boil down to “start from scratch” or “try to salvage something”.     If the business processes have simply been moved around and shuffled, it may be worth seeing what can be salvaged and used as a starting point as one begins again.   If you’re thinking about this option, I strongly suggest you consider a) whether this will save you much time and b) whether the “legacy” information will constrain the new BIA inappropriately.   In most cases, my preference would be to start from scratch after you have reviewed the relevant obsolete BIAs and BCPs to gain a good understanding of how things used to work.   Familiarity with the old reality gives you context for the new reality and enables you start the new BIA with an open mind.

In general, I think it a good idea to anticipate expected changes affecting your project and to plan accordingly.   If you follow the old “be good, be brief, be gone” principle, you reduce the window of exposure but you should always identify the risk of organisational changes as one of your project risks.

This entry was posted in Business, Observations and tagged . Bookmark the permalink.

Comments are closed.