And finally, here is the last part (Part III)…
14. Common Terminology – Blah, blah blah; yak, yak, yak. That’s all people will hear if you’re speaking to them in ‘tech-speak’ or using industry terminology and acronyms they aren’t familiar with. How often have you sat in a meeting where you miss what’s being said because of the various terms being used. Sure, you may know what they mean but don’t assume other do to. You’ve got to make sure you speak in terms your audience understand and use words they are familiar with. If you start off with stating BIAs will give us our RTOs and RPOs and not one knows what those mean, I can assure you that when you’ve developed the RTOs and RPOs, no one will agree with you because they didn’t have an understanding of what you were asking when you went through the BIA process. Speak in common terms or terms your corporation is familiar with, not ones you’re familiar with.
15. Develop for the User – When the crap hits the fan, there are people responsible and accountable to make things happen. They can make this happen if they understand what they need to do but that won’t happen if you’ve developed the plan for audit and governance people (among others) and not for those that will actually be using the plans and processes you’ve developed. In project management, if you want to be successful, you’ve got to make sure the end user is happy with what is being delivered. After all, they are the ones who’ll be using it and if they don’t ‘get it’ what you’ve created won’t be a success. I’m a firm believer that an action plan should start telling you what to do in a matter of a couple of pages; not 30 pages of the strategy used to develop the plan. That’s fluff material and can go into some other document with other fluff stuff. The actual plans must be quick and easy to follow and be understood by those that will be required to follow it. If they can’t follow it, it won’ t mean anything. All the hard work put into creating it go to naught because those that need it, can’t follow it or understand it. So remember, you’re delivering something to a user (group, division or individual), that can be understood, not delivering a huge binder that’ll end up being used to stop a table from wobbling.
16. K.I.S.S. – No, this isn’t Gene Simmons spitting blood and breathing fire and singing ‘Shout it Out Loud’ (which is a cool song and reminds me of being 10 again), this is Keep It Seriously Simple (aka Keep It Simple Stupid but in the age of PC, I thought I shouldn’t say that…oh, wait…). This means that you can’t over complicate things when speaking to others you need information from. You have to learn how to communicate in a way that they can understand and be able to provide you the information you need and assist with any actions you need. If you’re speaking to someone from Human Resources (HR), you can’t speak to them the same way you’ll speak to someone in Technology (IT). IT and HR speak different languages and you must be able to communicate so the audience understand you. This also means making things logical for them and not trying to teach them everything you know. You have your specialities and areas of expertise and so do they; you have to find a way to translate your detailed scientific DR/BCM/ERM details into something that is logical for them to understand. So remember to keep it simple…
17. Develop the Handoff Strategy – Not every person who manages the development of the BCM/DR/ERM program is the one that will stay as the lead of the program. Often, someone else is to take over and run it on a long term basis; they become the owner or manager of the program. If this is the case, all Project Managers must ensure that there is a proper hand-off strategy or Operational Hand-off from the project closure to Business as Usual (BAU). It would be chaos if the project ended and an individual was then approached and told, ‘this is yours’ and that’s that. They’ve got to know where things are and what was done and know what they are responsible for and what documentation/deliverables, they’ll be receiving. So ensure this process has been developed and the strategy is developed so that the hand off becomes as seamless as possible with the minimum amount of confusion and disruption. The smoother the transition and communication around it, the better chance the program has of continuing.
18. Manage to Scope – Like any project; beware of ‘scope creep,’ If you’re only doing a BIA for data centres, don’t get suckered into doing the BIA for regional offices. Or if you’re only to develop an alternate site for a single site, don’t end up doing it for others. It costs more for one and the original scope items will take longer to complete. It’s easy to let scope get out of hand. Small requests suddenly become large items that you’ve committed to and then you find yourself with no budget for it or resources/people to help accomplish it. There’s nothing wrong with capturing the extras people want to have done but you’ve got to record it (see the point about change management) and you’ve got to get approval to get it added. If scope changes then the time and money associated with it has to change as well. If they don’t and you still have to deliver the old scope and the new scope, you’ll find that quality may go down because the stress of budget concerns and resource/time concerns come into play. Some might know these as the ‘triple constraint;’ budget, time (or schedule) and scope. So make sure you manage scope; you can always have a Phase II later one that addresses any new scope items identified.
19. Celebrate Success & Learn From Mistakes – This is one of the most forgotten things in any project. Celebrate what you’ve done. Celebrate when you reach a milestone or accomplish a major deliverable. Recognize the team members involved. If people feel appreciated and part of a team, they’re more willing to ensure success for the project. This doesn’t have to be fancy awards or monetary gifts but small celebrations like going out for lunch or a simple ‘thank you’ can mean so much to team members. Remember, if the project succeeds it the team success, if the project fails, is the Project Managers fault. So celebrate and keep morale and spirits enthusiastic and high.
There are many other things to consider when developing a BCM/DR/ERM program but these items deal with the project management side of things and are intended to help you as you develop your program(s).
“Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility” and “Made Again Volume 1 – Practical Advice for Business Continuity Programs”
by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3