This is an interesting subject (thanks), >I had to confess to this customer that I had not seen much in the way of >"best practice" in this area.
Neither have I. So whatever I say next is just a practice that I've been testing its effectiveness. So it is extremely interesting for me to talk about and share ideas about this. I've been cross linking ideas from Feature Driven Development (Coad, Lefebvre, De Luca, ISBN 0-13-067615-2) with the ones exposed by Boiko's Content Management Bible (ISBN 0-7645-4862-X). The idea is to correctly and explicitly define client valued features cross linked with architectural constraints in order to establish development plan that includes product (or products) selection. This, in such way that boosts problem perception and diminishes the value of common acronyms (XML, METADATA, HTML, WEBSERVICES, WORFLOWS, VISUAL TEMPLATES etc). Furthermore the same documentation generated by these definitions can be reused to guide implementation/configuration after the product or products are selected. Client valued features are "things" that represent what processes a customer want to automate (web publishing plus whatever) and how each feature needs to interact with each other according to business engagement rules. According to FDD (Feature-Driven Development) a software development plan follows the following stages (my notes concern CM development plan, an adaptation of the SDP proposed by Coad et. al.: 1. Problem Domain Modeling (Develop an overall Content Model): This is where you gather information regarding content templates (a content template describes content of identical structure) and their relationships (Is there a relationship between a press release and product description doc, service description doc, or any other business doc?). Content Templates also define policies for content creation by defining what data is required and what is optional for a specific type of content ([Notification Letter]). You can also include here site-structure etc, etc (but not required). It's a good time to describe and review the XML Specs that the client wants to use. 2. Build a feature list (List of features grouped into sets and subject areas). An example of a "feature set can be Publishing an [SOP - Standard Operational Procedure] or [Book Section]" etc. Example of a feature can be "creating a [Notification Letter] for a [Citizen]. A subject set can be News-Management. Note that the information in brackets is actually names referring to Content Templates or Site Map Nodes as defined in step 1. Attached to each feature set or feature you may specify a workflow (parallel or not). This is probably a good moment to select your CMS. 3. Plan by Feature: You need to set who are the content owners and feature set owners. This people are the ones that will be responsible for managing the content. This people can tell you where data is stored and they reach it. This is important to establish roles and find the location of data. Location of data (database AS/400?, paper, etc) will mandate the features needed (Driver?) by the CMS's to deal with content integration. Collect information about what they need to insert data (editor's) etc. You really need to select the CMS now. 4. Design by Feature (add more content to your model). With your selected CMS you need to start showing things. 5. Build/Configure by Feature (Completed client valued function). This approach focuses on client valued functionality according to its automation intent. Why? Because, quite often this is unlikely to change much over time. This approach and concerning docs needs to be complemented with more two information sets (docs). * Architectural constraints - Databases to be used to store data, Technology to be used (Java/J2EE, MS.NET, Security technical constraints). The expected information throughput in and out (scalability). Editors, Template designer's. Preferred publishing method (Dynamic, Static both). Syndication interfaces (XML Schemas, etc etc). .NET Passport authentication, Google search interface, etc, etc. * Regulation driven constraints and other things - Multi-language support, support for people with less physical abilities, electronic signatures and policies for archiving, etc. The language you used to describe any of this can be whatever you and your client feels more comfortable with (UML, text, UML+text, etc). I use UML+text now. The phase 1, and phase 2 and sometimes 3 are the most important phases. Do it not so well you will: *) get less then what you need. *) get more then you need. *) not get what you need at all. Either way means more cost then expected. There is much more to say about this, I suggest buying the books and keep on sharing experiences. Hope it helped, Nuno Lopes Independent Consultant. PS: I agree with Tony Kisbey. Note, I'm not describing functions (that is how the system needs to function) but client valued features according to their intent. Functional documents quite often don't work and they are let forgotten on some shelve. If the domain is too big, compromises need to be (relaxing meta-data structure) done otherwise one's risks the project not to find its end but end in end is a matter of human resources and money available to invest. Nevertheless one needs to focus on client valued functions encompassing the content supply chain not technical functionality IMO. Experience with one CMS or another is most needed to cross check the sales argumentation and develop ones trust but is not mandatory. So one needs to check the sales argumentation not against some technical functionality but with the problem domain at hand and this can be usually shown in a demo or prototype. Squeeze the "demoer" to exhaustion and compare with others. The squeezers need to be someone(s) that knows what the problem domain (what is the problem domain?) is and have some technical grasp. Quite often in Portugal we find neither in the meeting with no disrespect to clients. If one can't find anyone with both skills I advise the client group to be mixed, but in this case please prepare the meeting before meeting the sales person in order not to waste the time of the sales neither yours (involving these people on phase on 1 to 3 is mandatory). -- http://cms-list.org/ more signal, less noise.
