We are familiar with time tracking, quoting and estimations to manage disasters and delays throughout a rollout. Blow-outs happen. Sometimes the best intentions can cloud a project’s objectives or mission when a subtle change in view occurs, or someone thinks the way they have done it before is quicker, smarter, newer, or sharper than the stepped project plan and the integrated disaster recovery plan.
Indeed, it may have been successful, or unbeknown to them; they may have been moved onwards to another project to allow recovery.
Preventing delays sometimes requires endless meetings and discussions on project deadlines and a realistic timetable. Keeping things genuine with the best decisions without a realistic timeframe will let slippages visit.
Occasionally a project rollout might fall behind when a team member leaves for various reasons. Project Managers must be across a dictionary of factors, but setbacks and delays happen.
Here is a story from the archives (*names changed).
Martin worked as a system administrator. It was a small and effective team who kept the programs and security as tight as they could. They failed to have a disaster recovery plan because they thought they were the disaster recovery team—a team without a plan.
Martin’s responsibilities included maintaining computers and keeping the assorted software up to date. He also viewed the security log daily for out-of-hours activity. Martin backed up the files daily and stored them in the company safe. Martin typically worked 3 hours after hours. One afternoon, a reasonably new hire, John, asked Martin to help him install the software. John showed Martin the fully signed appropriation, and John could see the approval on his logs. Martin asked John what the software did so he could record it in the software diary. John replied that it was business analysis software and produced great radar charts for his work. Martin needed to temporarily disable the security system to install the software for John. Later that evening, Martin had some challenges with the backup, but eventually, it ran okay.
What happened?
A few days later, Martin’s boss called and said he could not find his work files. A few minutes later, the sales manager, Linda, could not find hers. Then the accountant rang and said the stocktake froze. Everyone looked at Martin. He immediately went to his computer to check the security system. It was running on one server only. A user with the nickname j_oo3a erased all files on the primary server. It was John.
Martin restored the backup from 24 hours before. All sales data needed reinstatement, and the stocktake restarted. Martin returned to the boss’s office and reported. It turned out that John was walked out by the boss the day before because he said he accepted a role with their competitors. John took commercial information. Martin suddenly realised the installed program would allow this to happen repeatedly.
Martin’s boss logged the project delay and called their internal audit team, who reviewed Martin’s review before installing the software. It had ticked all the boxes, and Martin had correctly followed the steps. So how did this happen so quickly?
If it had been in place, the disaster recovery plan would have subtly altered the timing of Martin’s backup checks.
We help businesses, big and small, with writing disaster recovery plans. When combined, our wide variety of experiences pulls together many fine details.
It is not as costly as you may think. Compared with the cyber security reporting and recovery actions that Martin’s management then had to enact because of the possibility of the client’s data primary being breached.
Contact us to have a chat about getting your own disaster recovery plan written by an experienced independent set of eyes.