Many organizations call the development of their Business Continuity Management (BCM) program a project, which is not a problem. Developing the program is a project with a start date and an end date. At the end of the development stage, it is handed to a department as part of Business As Usual (BAU)…hopefully. One thing that many executives want to know is what it will cost to build the project. A fair enough question, if you ask me. The problem comes with the interpretation of what the cost of the project actually represents.
Too often, executives forget there are two very distinct costs associated with developing the BCM (or Disaster Recovery) program; one is the cost of the Project itself and the other set of costs relate to the ongoing Program. Here’s a quick distinction;
Project Costs: Just like a regular project, there are some specific costs associated to it. If you have multiple locations that a person must travel to, you’ve got food, travel and accommodation charges. You may decide to hire a 3rd party vendor/consultant to manage the project, so you pick up their costs as well. Then you’ve got your internal project costs such as IT personnel being involved, HR personnel, marketing personnel etc; all of which would be involved by representing their areas of expertise. You may also decide that you want to use BC/DR software, which would also be a cost for the project (and probably used by the program once the project aspect has completed).
One of the things to keep in mind is that each phase of your program build can be a project. For instance, the Risk Analysis (RA) might be one project and the Business Impact Analysis (BIA) might be another project. Then you can have the Contingency Development project and the Crisis Communication Plan development project; each will come with its own set of costs. What is your scope? Will you be doing a BIA for the entire corporation? A department or division? A single location or multiple
There are some things that can’t be included into your project costs though; the costs associated with contingency strategies. I don’t care what anyone says, until you know what you do, why you do it, when you do it and for whom, there is no way you know what contingencies you need.
Remember, a project has a start and end date and delivers (not maintains) a product or service within a specific amount of time, budget and scope. Beyond delivery, you move into the program costs. Oh, and if you decide to use a consultant to facilitate / manage your ‘project’ then those are project costs too. If you retain the consultant of the 3rd party vendor consulting firm, the ongoing costs after the initial project costs then move over to program costs – because it’s part of the ongoing maintenance.
Program Costs: These costs include items you wouldn’t know about at the beginning of your project. How could you possibly know what your contingency strategy will be – or cost – before you’ve even started the actual project to garner the information you need? You couldn’t. Do you require a 3rd party vendor contract for an alternate location? Do you require to purchase multiple backup servers and store them in another corporate facility? If you do decide to have a 3rd party involved on an ongoing basis, this cost and those associated with it, become part of the program cost (and its maintenance). You’ll be paying monthly subscription fees for a contracted hot/warm/cold site long after the project is over, so this can’t be part of the project itself. In saying that, the project will probably be a part of determining the correct recovery/contingency strategies and help identify if a there is a need for a 3rd party to be involved but the costs are ongoing and should be treated separately. It can get confusing because the costs associated with determining the need for the contracted site will fall within the project scope but the ongoing costs might now. This could also include not just the maintenance and subscription costs but the unknown costs to purchase “x” number of server and backup systems and tape drives (if not in the contract), which won’t be known at the outset of the project. If you do have a signed contract, any upgrades to it will be part of the ongoing program – not the project. This is because if you’ve got a signed contract and the rest of your components have been developed – Crisis Communications Plan, Department Business Contingency Plans etc – your project is over.
This is a grey/gray are that establishes itself here when you get to this stage of your program development. (I’ll be writring about the ‘hand-off’ to BAU later).
When executives or senior Management agree to develop the BCM/DR program, they often forget that the ‘project’ to develop it will be over at some point; it isn’t just delivered/developed and that’s it. If it’s to be a viable and usable program you either need to clearly make the distinction for them so they understand that when the project is over, the program isn’t, or you better pray for a crisis/disaster right away so that the program doesn’t lose the financial support and focus it needs to keep going.
I want to state that it does all depend on your corporation and how you manage your financial tracking and I am not proposing it must be distinguished as I’ve outlined in examples above. It really is up to you to make the decision but you’ve got to clearly state the two parts so that people comprehend that ‘it ain’t over when the project is over.’ For me, a sort of rule of thumb is; if it’s ongoing, it’s Program Costs, if it’s short term to deliver the project, it’s Project costs. Simple really.
What must be understood is that the project will end but the program won’t. To keep the program going, it will still need some financial support and this kind of financial support won’t be known up front when you present your business case for developing a program in the first place. It’s got to be communicated effectively from the outset or the financial well will run dry as soon as the scope of the project has been reached.
There is much more to the financial tracking of the project and program and I might write about those in future articles/blogs but for now, I’m just focusing on the initial set up and communication of the financials because if that isn’t communicated and presented effectively, you’re going to run into issues down the road.