Friday, January 15, 2010

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)

No comments: