RE: Standard list of WCMS features

This has been an excellent discussion, I'm just sorry for
only jumping back into it late in the piece...

There has been much talk about customisation. Yes, products
can be customised, but as highlighted by earlier posters, at
potentially a considerable cost.

In most situations, it is certainly no longer the case that
customisation is required. For common requirements, products
should just install "out of the box" in a matter of days (if
not hours).

For more complex or unique requirements, customisation will
always be required.

The key is to work out *realistically* what the CMS will need
to do over its lifetime (which may not be more than a few years).
While it's good to look at the new opportunities offered by
the technology, it must also be recognised that the limiting
factor is the *organisational change*.

For the first year of installing a CMS for the first time, the
focus will solely be on migration and "spring cleaning" of
content.

Only in the following year will moves be made to implement a
few more advanced features. So in the first two years, there
may be little need for a powerful CMS.

All of this can be thought about, and captured in the requirements,
so that there is a middle ground between "blue sky" wish-lists and
not looking to future needs at all.

Anyway, just my $0.02,
James

At 01:33 AM 30/04/2004, Mitchell, Christine L (EM, PTL) wrote:

>-----Original Message-----
>From: Austin, Darrel [mailto:[email protected]]
>Sent: Thursday, April 29, 2004 10:36 AM
>To: [email protected]
>Subject: RE: [CMS] Standard list of WCMS features
>
>...Software is malleable. I don't think enough companies understand that.
>They
>tend to accept whatever vendors tell them when they start hitting
>limitations of the product...
>
>Software is malleable if you have deep pockets when you start to hit that
>wall. Oh the pain of being at the mercy of a vendor whose product does not
>do what they said it would do without extensive (and expensive)
>customization. Then the additional pain that comes when they have an version
>upgrade but no clear upgrade path for your customizations. Then the
>additional, additional pain when it turns out that you now have a single
>point of failure, that one person who understands the customizations, and
>they leave.
>
>Much better to find a solution that works properly, does *most* of what you
>want without extensive programming customizations and can be easily learned
>by replacement. The prevailing thought that a CMS must have lots of
>customization to "fit the company" is vendor sales talk to position their
>professional services.
>
>I say write the software properly in the first place for a particular type
>of delivery (Web, records, documents, etc) and stop trying to sell yourself
>as being all things to all people.
>
>Sorry, but I learned the  hard way.
>
>Christine L. Mitchell
>Internet Content Manager
>Penske Truck Leasing
>www.pensketruckleasing.com
>
>
>
>_______________________________________________
>CMS mailing list
>[email protected]
>Subscription controls:
>http://lists.cms-forum.org/mailman/listinfo/cms
>Netiquette FAQ and related CMS lists - [CMS-Forum], [CMS-Meta], [CMS-PR], 
>[CMS-Develop]
>http://www.cmsreview.com/NetiquetteFAQ.html

-------------------------
James Robertson
Step Two Designs Pty Ltd
Knowledge Management / Content Management / Intranets

http://www.steptwo.com.au/
[email protected]