The soul of consulting is oversimplification. Making big scary problems appear so simple in their solution that decision makers will commit to taking on solving them. Hopefully with your services. Pondering the WikiLeaks fiasco it seems to me this is a classic opportunity for enterprise content management consulting and a case where requirements and expectations failed to meet.
What really happened in the leak? In simplest terms, a person made a copy of content from an environment and gave the copy to someone that should not have had it. Simple right? This is a very basic problem addressed or at least acknowledged by most ECM software. Every ECM product evaluated in the recently updated Gartner ECM Magic Quadrant provides access control,versioning and records management.
Many ECM vendors offer audit and reporting that could alert on access and provide search and analytics on the content. The best ones provide advanced security features like encryption at rest and in the transport layer. And don’t forget digital shredding at the storage level for content no longer needed.
None of these solutions to what in retrospect were obvious problems seemed to be in place in Cablegate. To be fair, there is next to nothing that can prevent a breach by a resourceful and vindictive inside man with access but at the very least they would have limited the damage.
So why were these features not present. Simple. The requirement for the system containing these cables was not to manage content. It was to facilitate communication. How we categorize a system has a dramatic effect on the eventual outcome. Clearly there would be overlapping features between “cable” management and ECM but approaching the problem from the these different but related perspectives create wildly different results.
Some would argue that this is a requirements definition problem. Who ever put the system in place failed to capture those requirements. Or worse yet somebody did capture them but they were ruled out of scope. I would argue rather that this is in fact an expectation rather than a requirement problem.
We talk in IT circles about managing expectations all of the time. It is usually just code for telling the users they are not getting what they want. What is the difference really between an expectation and a requirement anyway?
Not long ago my wife yells up two flights of stairs as she is getting in the car “Bring my black slip on shoes when we meet later.” (requirements)
Having seen my wife’s closet (experience with the customer) I yell back “Which ones?” (deep dive)
“The comfortable ones” she replies and then she is gone.(another requirement?)
At this point I am doomed but let’s look at the situation anyway. Since I am a frequent wearer of shoes myself I qualify as a subject matter expert(SME). Knowing from past experience that bedroom slippers are the most comfortable of all shoe types and seeing that there is a pair of black slip on bedroom shoes in the closet (product evaluation) the solution is obvious.
I have met the requirements – ahead of schedule and on budget I might add – I am ready to implement. When I make my delivery though I am immediately faced with an adoption problem.
“What do you mean they won’t work?” I inquire. “They are exactly what you asked for.”
“But they are not what I expected.”
At this point in the transaction a panic stricken project manager would be leafing through an SOW with a highlighter to try to convince my wife that walking through Target on Black Friday in slippers is actually a best practice but I digress.
As absurd as this frightening but true story is we see this scenario played out in IT departments on a daily basis. I imagine some time in the distant past a contract programmer analyst trying to follow a hurried State Department SME down a hall to get requirements and being told – “I just need a system to send messages electronically from this guy here to that guy there.”
“Anything else?”
As the elevator door closes the SME says “Make it easy to use”- the technical equivalent of comfortable.
The often demonstrated inability of IT to look past requirements and into expectations is a pervasive problem. The State Department expected the system to do more than deliver messages. They asked for communication but they expected the system to secure(manage) the content. Was it a requirement? Doesn’t matter. It was expected. There is no rational defense for saying access, audit controls and reporting were out of scope for classified material whether it was in the contract or not.
The argument will be made that the network was supposed to be secure therefore the application is not at fault or the requirements changed because two million people now have access to the system. To put it in the nicest technical terms – that’s hogwash. Playing expectation tennis where you lob them at another department doesn’t cut it when lives are at stake.
Much of what we do in technology doesn’t matter. I have long described my role in content management to the uninformed as putting pictures of toilets on the internet. There are however some jobs in content that must be held to a higher standard. Not just a technical standard but a standard for common sense.
The point of this piece is that it is our responsibility in technology to do our best and constrain stupidity – especially when our failure can lead directly to a loss of life. Implementing to meet the expectations rather than the requirements by application of basic principles that are part and parcel to our daily work would have prevented this from happening.
The frustrating thing is I have no doubt there were dozens, if not hundreds of people that identified the potential for this leak and were ignored. I also have no doubt that this system has been the source for leaks from our government from day one. We only find out about it now because the material finally reached a self promoting ideologue with an agenda and a death wish instead of a foreign government incented to keep the information flowing.
The system will be fixed. Controls will be put in place. The tragedy is that it is all too late. Confidence is lost. It will be a generation before State Department officials will be able to speak their mind electronically again. Decision making will suffer and mistakes will be made as a result. And in the archives somewhere there is a record of a successful project completion where requirements were met, functionality was delivered and the system failed us all.
In case you are wondering – the shoe story is 100% true. Being an experienced husband and project manager though I had a contingency plan – I took “shopping shoes” too.