|
 Valuable CMS Lessons Learned
By Geoff Choo,
Tech Republic
July 25, 2002 - ZDNET - Sooner or later, tech leaders learn that
it's far easier to screw up a content management system (CMS) project than
to get
it right.
CMS is a risky endeavor because it is complex, costly, and involves a
myriad of people and processes. CIOs also have to deal with the push and
pull of conflicting ideology and conflicting business needs, and get people
with diverse skills and backgrounds to work together side–by-side without
killing one another.
The goal is not to let today's risks become tomorrow's problems. One of
the best ways to avoid costly CMS mistakes is to learn from other tech
leaders who've traveled the CMS road before you.
Putting the cart before the horse
"Our first CMS (and unfortunately my last) project turned out to be a
disaster because we stupidly let the cart pull the horse. We got so
enthralled with the CMS product that we based our purchasing decisions on
what features and functionalities impressed us more, rather than on what our
organization really needed. In the end, we had an excellent CMS platform,
but it didn't do what our organization needed it to do." --Tom M., Business
Manager
Once CIOs decide that they need a CMS, the main mistake they typically
make is buying the "coolest" product before figuring out what they really
need. While you certainly need solid technology to make a CMS work, it's not
productive to select a package before you have a created a comprehensive
requirements roadmap that ensures that the solution you buy, build, or rent
exactly meets business objectives, needs, and budget. Answer these questions
before even looking at potential solutions:
- Do you have a sound understanding of your business goals and
objectives and a detailed understanding of functional and feature
requirements?
- Have you identified the critical content problems?
- Do you know your content management, publishing, and technology
integration needs?
If you select a product without first identifying what your company truly
needs, the product inevitably ends up driving the system--your people,
processes, and even the content itself--rather than other way around. |
