WikiLeaks, Expectations and ECM

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.

8 thoughts on “WikiLeaks, Expectations and ECM

  1. Not meeting expectations and letting unchallenged assumptions go sometimes starts right at the beginning, in the process getting the sale, making a deal, or simply getting the contract process done.

    This is a tough business we are in isn’t it?

    Great post.

  2. it is a tough business indeed. For the seller as well as the buyer!

    thanks for the comment

  3. One of the real challenges is the changing role of IT folks over the years. The role has morphed from subject matter experts with nominal business experience to the electronic equivalent of plumbers. If the drain is slow or the pressure isn’t high enough, fix it. There is also the challenge of a lack of responsibility. Many of the IT folks I work with are not empowered to be responsible for the inevitable business consequences of sloppy ECM or ERP or even email management. They are asked to fill the requirements of other business users who have little grounding in the “law of unintended consequences”. Thanks for the perspective, Lee!

  4. Hi Lee,

    Loved your ‘expectation versus requirement’ analogy.

    It seems to me that this is an excellent example of why a ‘Model Office’ approach to implementing an ECM solution could be beneficial to organisations … in that the Model Office would provide a means for end-users to refine their requirements, visualise and explore how their requirements could play out within an ECM solution, enabling them to interject early on and set expectations … all helping to tip the balance in favour of wider end-user adoption.



    1. Hi Adrian and thanks for the comment.
      model office is something I had not considered before in those terms.Interesting concept and it has precedent. Retailers for example have test stores where layouts, merchandising and other store physical systems are run in full scale for a number of purposed before rollng them out. I can see where modeling a knowledgeworkers experience in full scale beyond just a functional application pilot can be useful to reduce risk in rollout – especially where new equipment (scanning, printing, etc) are involved.

Comments are closed.

Create a website or blog at

Up ↑

%d bloggers like this: