Here’s a fun article about a guy who accidentally deleted everything from all his company’s servers, including all his off-site back-ups too – in effect, deleting his entire company. As you can imagine, the forums weren’t especially helpful.
Man accidentally ‘deletes his entire company’ with one line of bad code
“Well, you should have been thinking about how to protect your customers’ data before nuking them,” wrote one person calling himself Massimo. “I won’t even begin enumerating how many errors are simultaneously required in order to be able to completely erase all your servers and all your backups in a single strike. This is not bad luck: it’s astonishingly bad design reinforced by complete carelessness.”
A timely article, as there’s a project underway here to look at the feasibility of replacing one MIS with another and how we’d manage the data migration that that would entail.
It’s not just a matter of moving bytes around though. The horrible mess-up above notwithstanding, that’s the easy part. When implementing a new MIS there’s as much people stuff to resolve as techy stuff.
Here’s an interesting essay from the University of Michigan, from a dim and distant past when universities and other large organisations were wanting to move away from mainframes to more networked environments.
Implementing an MIS
The implementation of a management information system can be a traumatic experience. At a minimum, changes in procedures will impact the ways in which plans are made, programs are developed, and performance is evaluated within the organization. New patterns of communications will emerge, and new – presumably better – information will be available to assist in carrying out decision-making and administrative responsibilities. Efforts to improve the MIS may also uncover the need for organizational changes which may be even more unsettling than the procedural changes necessary to implement the system. The introduction of a MIS may represent substantial change in the established way of doing business, which can be viewed with considerable alarm (and generate significant resistance) by those within the organization.
Different technologies, but the same concerns.
I found the principles proposed at the end of the article very interesting, and hope that a similar approach will be undertaken here.
It is important not to oversell the potential of the new system. Aaron Wildavsky offers a number of “rules” that are applicable to the implementation of any new management system. The rule of skepticism suggests that organizational officials should exercise a good deal of skepticism when presented with the initial concept of an improved management system. The rule of delay cautions officials to give the system adequate time to develop and to be prepared to face periodic setbacks in its implementation. As Wildavsky observes: “if it works at all, it won’t work soon.” The rule of anticipated anguish is essentially a restatement of Murphy’s Law – “most of the things that can go wrong, will.” Wildavsky suggests that management must be prepared to invest personnel, time, and money to overcome breakdowns in the system as they occur. And the rule of discounting suggests that anticipated benefits to be derived from the new management information system should significantly outweigh the estimated costs of mounting the system. Much of the cost must be incurred before the benefits are achieved. Therefore, the tendency is to inflate future benefits – to oversell the system – to compensate for the increased commitment of present resources.
And let’s not forget that Hofstadter’s law applies here too, as well.