There Is No Such Thing As "Unstructured" Information

All information, content, documents, chunks have implicit and explicit context and metadata associated with them, therefore they are structure to a certain degree. One of the major issues of keeping tracking and finding content can be solved if the “who” in the equation is dealt with.

Take Records Management. First, the concepts are agreed upon; second, “we have to get something out” requirements are decided on; third, the tools are picked; finally, the issue of how to tag the information is arrived upon. Oh yeah, the creators of the content. How to get then to change the way they tag information, their habits of thinking around identifying their content for world consumption?

The legacy content is another issue altogether. Are you going to force authors to tag and reorganize their whole c: drive? Are you going to auto categorize the share drive and hope your taxonomy is comprehensive enough? Are you going to set up a master/proxy that layers a meta metadata structure on top of everything? Will there be a hybrid approach to humanly sort out the who, what, when, where, how, why (Zachman).

The point here is that it’s the Users, the corporate culture, that have to change their modus operandi. Sound familiar KM? How many times do we have to come up with applications that work around the ultimate issue of training users to think in terms of the group and the community, of sharing not hording ideas and knowledge? Social applications like Facebook will slowly seep into the minds of corporate Users and break this road block wide open.

Let’s hope that Center Stage grabs this trend and really takes off. If it’s easy to configure during a customer demo like SharePoint is, then maybe it has a chance. The overworked, whittled down IT departments out there want easy to administer enterprise software, that can be mostly configured. As soon as Documentum builds in a more comprehensive configuration tool (yeah I know Composer, right, not quite) the issues of customizations breaking or being too focused will be a problem of the past.

File shares in corporations are not “unstructured”. They actually are very structured, but to an indexing application with a taxonomy, they are “unstructured”. The real issues are change management of User behavior and ECM applications, governance with a small stick, and software that IT can be lazy and cheap about. SharePoint is already the next dumping ground, but User’s have learned just a baby step more about tagging their content so that others can find and understand it.

Diagnosing an ECM illness

As ECM projects and systems grow through awkward teenager years and start to show signs of age, there inevitably comes a time when symptoms of an illness show themselves and can’t be ignored any longer. The existing management is usually blind to the issues. The issues are inherent in how they make decisions and thus restructuring the governance and budget process is usually part of the treatment.

Symptom:

• Lots of Testing on Production and extended down times for maintenance.
  

Diagnosis:

• Lack of QA environment that is exactly like Production to validate test scripts
• The more testing, the more risk of extended downtime and possibility of rollback
  Relaxed emphasis on testing and more attention to deadlines

Treatment:

• Create a QA environment which matches Production down to the hardware (to test server swaps).
• Establish a mandatory QA and Validation process for the QA environment, thus reducing the risk of running major tests in Prod.
• Schedule more time than anticipated for testing in QA
• Budget extra resources for testing
  

Symptom:

• Unorganized folder structures and search results that are useless.

Diagnosis:

• No taxonomy standards
• Lax governance
• Fuzzy goals for business requirements
• No discipline in term of awareness of others who are outside of the team
• No training of common principles of organization
• Poor change management
• No organized Taxonomy: lack of governance, training, standards
• Bad search results: bad metadata, values are too haphazard
  

Treatment:

• Establish goals and standards
• Create a governance structure that can force business units to change
• Study current structures and come up with a plan to rebuild them with the acceptance from the key stake holders.
• Train superusers on information architecture
  

Symptom:

• A call for “re-branding” an implementation

Diagnosis:

• Managers did not listen to the subtle whispers of dissatisfaction with the product.
• UI complaints accumulate, they don’t just happen.
• There are other factors that prevent upgrades to existing software or new software to replace outdated solutions.
  

Treatment:

• Illicit feedback and make changes continually
• Identify the lack of awareness of management to issues of business productivity
• Identify why the system lasted so long in its current condition without treatment
• Create mandates to leap frog to new technology every few years
• Design and architect for change

Symptom:

• Extended Downtimes in Production due to performance and scaling issues

Diagnosis:

• No Failover or HA to fall back on during inevitable times of failure
• Cutting corners on budgeting and resources
• No QA environment for performance testing
• Lack of enterprise architecture plan and resources

Treatment:

• Budget for failover contingency in hardware and software
• Create a QA environment
• Understand the lessons learned from the whole solution development lifecycle: where things went wrong and steps to take to remedy the issues.
  

Symptom:

• Postponing/rescheduling work execution due to emergency, “all hands on deck” system downtime triage

Diagnosis:

• Poor program and project management
• Poor resource management
• Resources that are not trained and experienced enough
• Sign of a series of mistakes during the whole project, no one resource is to blame

Treatment:

• Have clear goals stated up front
• Do not cut corners to meet bogus timelines
• Make sure there is enough time allotted for testing
  

Symptom:

• Slow performance

Diagnosis:

• No architecture plan for scaling of the application
• Lack of performance testing in QA
• Too much leeway given to power users who are not trained enough and only care about their own content
• Poor budgeting process
• No standards for change management

Treatment:

• Transfer the management of the application if this has been going on for a long time
• Architect a solution from the ground up which is flexible and scalable enough to deal with the use and capacity issues
• Think about dividing up the applications if the current one is monolithic

Symptom:

• Stealing infrastructure for other higher priority projects

Diagnosis:

• Poor communication from management of goals and forecasts
• Management is feeling pressure to succeed after a few failures
• Infrastructure procurement process is too slow to be effective
• Resources are frustrated from infrastructure and architecture to implementation teams
  

Treatment:

• Budget and purchase hardware well in advance
• Do not accept a project if it entails cannibalizing hardware and resources from other projects unless the whole teams is fully on board with the sense of urgency

Symptom:

• Infighting during deployment planning meetings

Diagnosis:

• Lack of cohesive governance
• Favoritism within the teams or from higher up
• Lack of trust
• Lack of common understanding of goals or standards

Treatment:

• Create common understanding of goals and standards
• Communicate often and effectively with the team(s)