In business continuity planning (BCP) and disaster recovery planning (DRP), its commonplace to urge planners to create initial plans and then test them for ways to improve. This approach is parallel to the current standards of software development and risk management. In the 1960s and 1970s, the standard software development methodology was the system development life cycle (SDLC), in which analysis, design, and approvals of the complete design were so onerous that delivery of finished software could be delayed by years. Since the 1980s, a much more common methodology is spiral development, which was originally called rapid application development (RAD), joint application development (JAD), or iterative, agile and incremental development.
Spiral development teaches us to incorporate the Pareto Principle (the 80/20 rule) into any project. If much of the desired result can be achieved with modest effort / resources / time, then it makes sense to get a first-cut version of any project in place before trying to refine it. Effective risk management takes advantage of incremental gains by instituting the best available defences and policies and then improving them; “lessons learned” is often used in after-incident reports (post mortems) on such systems. It would be ridiculous to have no defences or policies because they wouldn’t be perfect.
When I proposed the Master of Science in Information Assurance to the University Curriculum Committee at my university in 2002, I was astonished at the reaction of a humanities professor. He said that there was insufficient evidence from scholarly research to be able to judge the proposals, and therefore, the entire project should be delayed for at least a year as we provided the Committee with additional grounds for believing that the program would be successful. Luckily, I convinced the rest of the Committee that we would be revising the program constantly (continuous process improvement again) and would learn from experience.
And that’s what we did: we accepted a first class of 15 students in September 2002 and have been revising and adapting ever since.
Recently I was thinking about how these principles from systems engineering and information assurance can be applied constructively to ordinary life. I was prompted by memories of a discussion with an old friend many years ago about taking care of his disabled daughter after he died. To my surprise, I had ended up using the principles described above in our discussion of his will. I’ve changed identifying details in what follows to protect his survivors’ privacy.
Bob, now deceased, was then a 95-year-old retired history professor from a Midwestern university. He and his 93-year-old wife Frannie had discovered that their daughter Judy, then in her sixties, suffered from a severe personality disorder that had put her on psychiatric disability from the state where she lived for many years. She could live by herself only with great difficulty.
In our discussion, I asked what measures had been put in place in Bob and Frannie’s wills to ensure that Judy could be financially secure after her parents died. To my horror, Bob said that they were still thinking about it. They wondered how to insulate Judy from her own tendency to become obsessively committed to particular political causes; they thought that if she gained access to a lump sum of inheritance, there were good chances that she would impulsively give it away to her favourite political action group (she was particularly concerned with wildlife preservation) in an emergency. Bob and Frannie were also devoted supporters of good causes, but they worried that Judy would be destitute, with no provisions for her own well-being.
Bob emphasized how he and Frannie had been “thinking about” the problem for a decade but still had not decided on the “perfect solution.” I was horrified. I insisted that as Voltaire wrote, the perfect is the enemy of the good; waiting until all possible objections and eventualities were resolved could result in never actually acting at all. Indeed, Bob and Frannie had not included any details about how to protect Judy against her own mental disabilities in their will because they did not want to offend her.
For example, in Bob and Frannie’s case, it would have been a good idea to have a will in place assigning Judy a trust fund from which she could draw periodically (every month, maybe) under the control of an executor rather than allowing the inheritance to be delivered to her in a lump sum. With that safety-net in place, the parents could then work on improving the arrangements. But not having anything in place was asking for trouble.
And trouble there was.
Bob died in 1998 and Frannie, as is so common, died shortly thereafter. They had never completed their will, so Judy inherited the estate in toto. When 2001’s terrible events of 9/11 occurred in New York, she was so moved that she gave away the totality of her inheritance to help victims and their families – admirable and loving, but she was left to survive on a pittance from the state. She was eventually thrown out of her apartment because of a citation from the public health officers in her city when her landlord reported that her obsessive hoarding had resulted in a dangerous situation – her apartment was crammed floor to ceiling and wall-to-wall with hundreds of disintegrating cardboard boxes full of old clothing, useless crockery, and ancient magazines. Apparently she had even dragged in a filthy, stinking, soiled mattress salvaged from a garbage pile “because it might be useful.” She disappeared after the eviction and no one knows what happened to her or whether she is still alive.
The principles of spiral development apply not only to software engineering, business continuity planning, and disaster recovery: they can be helpful in any enterprise where we are developing something new or unique and cannot simply apply an existing model to meet our needs.
Don’t let the quest for an illusory perfection ruin a perfectly good project. Get on with the best you can do and adapt. Remember: Reality Trumps Theory!