selection « Content Here

Archive for the ‘selection’ Category

In-Context and Power User Interfaces: One for the Sale, the Other for the Content Manager

Monday, February 1st, 2010

A dirty little secret in the CMS industry is that, while in-context editing is often what sells a CMS, the “power user” interface is usually what winds up getting used after implementation. This phenomenon obviously creates problems in the selection process because, when the sales demo focus on an interface that users will quickly grow out of, any usability impressions are irrelevant. This is also part of a bigger problem: the importance of in-context editing for sales has caused many CMS vendors to neglect their power user interface.

It is easy to understand why the sales demo gravitates to the in-context user interface: the audience finds it more intuitive. What is less obvious is why. In a typical CMS sales demonstration, the audience has the perspective of a site visitor. After all, this is not their site. They have no responsibility for it. As a site visitor, we think of editing the content that we see: “I see a typo;” “that sentence is hard to read;” “I would prefer to see another picture here.” The user just wants to go in and fix it — like a Wikipedia article. Until it’s fixed, that content issue is going to bug the user so directness and immediacy are critical. Like with a wiki, the in-context is ideal for solving these kinds of problems.

The content manager, however, has an entirely different perspective. The content manager is thinking more about the whole web site than any one page. The content manager has to solve problems like re-organizing the website and making global content changes. Needing to manually change every single page of a website is not acceptable so content reuse should be top of mind. From this perspective, the appearance of a page is less important than the actual content, which also includes information you can’t see on the page but drives the behavior of the site. You can even go so far as to say that the visible page (what the visitor sees) actively hides information that the content manager needs to see. The visitor shouldn’t know where else a piece of content is featured on the web site or what caused the personalization logic to show this item in this particular case — but the content manager does. Incidentally, this is why you should make product demos focus on scenarios. Scenarios force you to think about what the content manager does – not just dream of being able to edit somebody else’s web site.

Yes, you can make the argument that the occasional content contributor (who 80% of the time experiences the site as a visitor) needs a simplified user interface to fix the issues that they notice or keep a few bits of information up to date. But, as an organization gets more sophisticated with managing content, those cases of simplistically managed pages (with no reuse and no presentation logic) get less frequent. At that point, you are just talking about the “about us” page and some simple press releases. Are you surprised that this is what your basic generic CMS demo shows? Furthermore, I am beginning to believe that the occasional user is a myth (another blog post).

In-context editing interfaces are steadily getting more powerful by exposing functionality like targeting and A/B testing but there inevitably comes a point when the content manager wants the full power of the application at his fingertips. As the in-context editors get better, that point gets pushed further out. But adding complexity and power to the in-context editing interface will no doubt steepen the learning curve for the occasional user and minimize the wow factor of the demo. And no CMS vendor will do anything to reduce the wow factor of their product demo.

Posted in selection, usability | 6 Comments »

CMS Architecture: Managing Content Type Configurations

Tuesday, January 19th, 2010

Warning: this post is highly technical. Non-programmers, please avert your eyes.

Deane Barker (from Blend Interactive) and I have a running conversation about CMS architectures. One of the recurring topics is how content models and other configuration is managed. There are two high-level approaches: inside the repository and outside the repository. Both have their advantages and disadvantages.

Managing content types outside the repository
My preferred approach is to manage content type definitions in files that can be maintained in a source code management system. This way you can replicate a content type definition to different environments without moving the content. Developers can keep up to date with changes made by their colleagues. Configuration can be tested on Development and QA before moving to production. There is no user-interface to get in the way. No repetitive configuration tasks. Everything is scriptable and can be automated. I especially like it when content types are actual code classes so you can add helper methods in addition to traditional fields. Of course, when you get into this, it is a slippery slope into a tightly coupled display tier that can execute that logic.

On the downside, it is often difficult to de-couple the content (which sits in the repository) from the content model (which defines the repository). When you push an updated content type to a site instance, you might need to change how the content is stored in the repository. This is more problematic in repositories that store content attributes as columns in a database. It is less of a problem in repositories that use XML or object databases (or name-value pairs in a relational database) where content from two different versions of the same model can coexist more easily.

If you do manage content type definitions outside of the repository, a good pattern to follow is data migrations, which was made popular by Ruby on Rails. I am using a similar migration framework for Django called South. Basically, each migration is a little program that has two methods: forward and back (“up” and “down” in RoR. “Forwards” and “backwards” in South) that can add, remove, and alter columns and also move data around. The forward updates the database, the backward reverts to the earlier version.
Managing content types within the repository
Most CMSs follow the approach of managing the content type definitions inside the repository and provide an administrative interface to create and edit content types. This is really convenient when you have one instance of the application and you want to do something like add a new field. There is no syntax to know and application validation can stop you from doing anything stupid. Some CMSs allow you to version content type definitions so that you can revert an upgrade.

When you have multiple instances of your site, managing content types can be tedious and error prone if you need to go through the administrative interface of each instance and repeat your work. Of course, you can’t copy the entire repository from one instance unless you want to overwrite your content. If your CMS is designed in this way, you should look for a packaging system that allows you to export a content definition (and other configurations) so that it can be deployed to another instance. Many CMSs allow an instance to push a package directly over to another instance. The packaging system may also do some data manipulation (like setting a default value for a required new field).

Unless you are building your own custom CMS, this all may seem like an academic question. It really is quite philosophical: is configuration content that is managed inside the application or does it need to be managed as part of the application. The same thing goes for presentation templates (but that is another blog post). However, if you intend to select a CMS (like most people should), it is important to understand the choice that the CMS developers made and how they work around the limitations of their choice. If you are watching a demo, and you see the sales engineer smartly adding fields through a UI, you should ask if this is the only way to update the content model and if you can push a content type definition from one instance to another. If the sales engineer is working in a code editor, you need to ask how the content is updated when a model update is deployed.

Posted in architecture, django, selection | 4 Comments »

Presentations from the Boston Gilbane Conference

Friday, December 4th, 2009

I am catching up from a whirlwind of activity at the Gilbane Conference in Boston this week. I gave three presentations (below), organized a breakfast for open source CMS software executives, and had a great time talking with so many industry friends. It was particularly nice to meet people like Scott Liewehr (@sliewehr), Scott Paley (@spaley), Jeffrey MacIntyre (@jeffmacintyre), and Lars Trieloff (@trieloff) who I had known only virtually before. I wished I could have stayed for the third day of the conference but I had to get back to work. Everyone seemed to feel very positive about business and where content management is going so I left brimming with enthusiasm for 2010.

What follows is a brief run through of the presentations I gave.

Open Source WCM and Standards

View more documents from sggottlieb.

On Tuesday morning, I did a presentation called Open Source WCM and Standards for the CMS Professionals Summit. To summarize, open source really has nothing to do with open standards but there are some areas where they converge. “Open source” describes a license. Any software can be open source if it is assigned an OSI-compliant license. Open standards is about software design — technology choices about what standards to support. That said, there are three areas where open source and open standards converge:

when an open source project is started to create a reference implementation for an emerging standard (note, on slide 5 I didn’t say that Alfresco was created as a reference implementation for CMIS, you had to be there.);
when there is a chicken and egg problem of value and adoption (like RSS and now RDF) some open source projects have the install base to easily create widespread support and a lower hurdle create an implementation;
projects driven by developers tend to put a higher priority on aspects like integration and attention to technical detail than marketing driven products which are more feature oriented.

How to Select a WCMS

My “How to select a WCMS” workshop is turning into a signature presentation for me. There was not too much difference from prior presentations of this workshop except this time I went into more detail on using doubt to make a decision. At that time, my friend Tim McLaughlin, from Siteworx, had popped into the room. He told me afterwards that he agrees with the approach and even read a scientific paper that found that the best decision makers use this method of elimination for choosing. Tim, if you are reading this, you owe me that link!

One particularly interesting part of that worshop was that one of the audience doubted the necessity of content management systems in general. So I was put into the position of having to defend the industry. He was coming from an organization that was managing 100 very small, unique, independently managed, and unimportant websites. In this case, I had to agree and I used the metaphor of a factory. You don’t build a factory to produce less than 10 units. A CMS would not help him until he started to try to manage all those websites in a more uniform way. For the time being, I suggested that he look into Adobe Contribute which handles basic things like deployment and library services without trying to manage reusable content.

Open Source: what’s it to you?

Open Source Whats It To You

View more documents from sggottlieb.

I presented with Kathleen Reidy from The 451 Group on “The rise of Open Source WCM.” Kathleen had some great slides talking about commercial open source vendors in the market. My presentation was from a buyer and implementer perspective. The general message was that buyers have the benefit of more choices and more information but they also have the responsibility to take a more active approach to selection. They can’t expect an analyst firm or salesman to tell them what is the best product. They need to understand their requirements and implement a solution that solves their business problems. Open source software suppliers depend on customers doing more pre-sales work themselves and they pass that savings back in the form of no (or low) licensing fees.

The biggest disappointment was when Deane Barker misunderstood slide 5 and tweeted that I think that open source is like a free puppy. Of course, this was re-tweeted several times. As I have said, all CMSs are like puppies: some are free, some cost lots of money, but all require care and feeding. If you have the intention of owning a puppy and understand the costs involved, you appreciate that a free puppy is less expensive than a puppy that you have to buy. If you spontaneously come home with a a puppy just because it was free, you might be in for an unpleasant surprise. Similarly, if you adopt a CMS just because it is free and you have not budgeted for properly implementing a website, you will get into yourself into trouble. Later, Deane and I had a great dinner together with David Hobbs before I headed back home.

Posted in conference, open source, selection | No Comments »

When it is not all about the software

Friday, November 20th, 2009

When I help companies through a CMS selection, I focus on the whole solution rather than just the functionality of the software. Factors such as vendor compatibility and expertise availability (internal and external) also affect the sustainability of the solution &mdash sometimes even more than the feature set. Several of my recent consulting projects have de-emphasized the software component of the solution even more. These selections were part of larger initiatives that required significant help from an outside partner. In one case there was a comprehensive site redesign that included digital strategy, re-branding, and information re-architecture as well as implementing new functionality. In another case, the client was shifting to an outsourced model where a partner was to maintain the full infrastructure and assume all development responsibilities. In situations like these, while the software is important, the biggest risk is choosing the wrong partner to work with.

A dual selection like this poses a real problem. If you focus on the partner, you have the software choice made for you. I know that there are systems integrators that claim technology agnosticism but I seriously doubt them. The truth is that it takes a couple implementations on any platform to get it right. In some cases, it takes many (like 5) projects to run out of ways to mess things up. That is the downside of flexibility. So, when someone says “technology agnostic,” I hear either “we don’t have skills on any platform” or, like the the waitress at Bob’s Country Bunker said: “Oh, we got both kinds [of music]. We got Country, and Western.” It could be even worse: the integrator who claims neutrality can be paid by the software vendor to recommend a solution.

The other option is to go with a pure design agency and select a product (and integrator) afterwards to implement that design. This can be inefficient because the designers can arbitrarily and unknowingly make decisions that make implementation harder. You will probably need to rescope and refactor the design based on the native capabilities of the platform you choose. A lot of time can be saved if you have someone to suggest more efficient options during the design process. I know I am going to get slammed here by developers and software companies saying their product can do anything. If they could, they would have 100% market share. Pure strategy and design companies also tend to underestimate the cost of implementation so you might running out of money when it is time to implement the design.

It’s a chicken and egg problem. You can’t choose a product until you have had help with your requirements and you can’t get help with your requirements until you choose a development agency (that implicitly comes with a product). I have found this variation of my standard process to be effective.

Gather the requirements that are the most meaningful to a product selection. I call these leading requirements.
Use these functional and non-functional requirements to filter down the software marketplace to a very short list of product options (probably no more than two).
Find a couple of the best web agencies who specialize in working on either of these platforms — ideally, two for each of the two products.
Invite these agencies to present a solution based on their preferred platform. Like in my normal selection process, the presentation consists of the demonstration of scenarios that you defined when you gathered your leading requirements.
Evaluate the presentations across two dimensions: the product and the agency.

I have found this process to be extremely effective. The benefit that I didn’t anticipate was that the preparation of the prototype tested three very important aspects of the integrators: their consultative process for turning customer articulated requirements into a solution; their mastery over the platform; and their relationship with the software vendor. But the process is not perfect. Here are some issues:

A professional services company has lower margins than a software company. They don’t have the prospect of an all-profit software license deal to justify a big bet on a sales initiative. Professional services companies will put up with a lot less run around than a software company will — especially the good ones. So the process has to be efficient and they need to have a good shot at winning. This means that you need to: have a short list of no more than four integrators; have budgeting worked out before you contact with them; and work together with them to get what you need. This collaboration is also useful in getting a feel for what it will be like to work with the firm.
Some integrators have dedicated sales teams that can prevent you from getting to know their consulting capabilities. You should do everything you can to work directly with real consultants. Not only is it important to learn about their style and capabilities, delivery staff are less likely to tell you what they think you want to hear.
Those filtering steps (1-3) are very hard if you are just learning about web development and don’t know your way around the industry. You need to talk to lots of people and learn from their experiences or work with someone who has.

Despite all of these challenges, doing a dual selection is not impossible. In fact, it can be quite fruitful. You just need to be focused and disciplined in your approach and execution. If you are interested in learning more, I am teaching a workshop on Selecting a CMS at the Gilbane Conference in Boston on December 1st. I hope to see you there.

Posted in conference, selection | 4 Comments »

Deane Barker’s tips on requests for proposals

Monday, November 16th, 2009

While it may seem counter-intuitive to listen to a supplier telling you how to buy, you should definitely read Deane Barker’s article “Five Tips to Getting a Good Response to a Content Management RFP.” Deane is a co-founder of Blend Interactive, a web design and development firm. That may put him on the other side of the negotiation table but, as a potential partner, he wants you to be successful in your initiative as much as you do. That is actually not so out of the ordinary. As a consultant, you want to spend your time with clients who you have a great working relationship with. The better consultants can be more selective in the opportunities they pursue and nothing sends off more bad vibes than a dysfunctional selection process.

The article agrees with all the advice that I give on my blog (it even quotes me!). The one tip that buyers are going to question is openly stating budget. I tend to go back and forth on that myself. The benefit is that budget is the best way to communicate what you think the size of the project is. Getting that piece of information out in the open early will help the vendor present a solution that is in line with what you had envisioned. It also reduces the risk of harboring unrealistic expectations of what you can do. The risk of communicating budget is that the integrator will inflate the price to maximize margin. My current thinking is that you shouldn’t be working with a partner who you fear will take advantage of you. You should structure your selection process to verify the integrity as much as the skills and experience of the vendor.

If you are in the market for a development partner, read these tips. If you can get to Boston next month, you should join me in my CMS Selection Workshop at the Gilbane conference. In fact, Deane is going to be there too.

Posted in conference, selection | No Comments »

Should you host your intranet and corporate website on one platform?

Tuesday, November 10th, 2009

Often times by the time a client gets to finding me, they have reached a point where they are ready to throw away their entire web infrastructure: both their corporate website and their intranet. They hope that one well executed product selection can solve both problems. When approached by this kind of prospective client I am careful to set the expectation that this hope is probably not realistic — not impossible, just not realistic. That said, there are a few conditions where putting your intranet and external website on one stack does work. Here are the criteria that I use.

The intranet is informational rather than collaborative. Different people mean different things when they say the word “intranet.” For some, an intranet is just a collection of web pages that only employees can see. Others think of tools and workspaces that allow employees to collaborate and get things done. If you had the latter in mind, chances are you will be looking for a document management, ECM, or portal system like Sharepoint for knowledge worker collaboration. These systems are technically capable of pure web publishing but that is not their strength. Your website management team will feel constrained by a platform that treats web publishing as an afterthought. If you think of your employees and customers/prospects simply as different audiences that you need to publish to, a single platform may work just fine.
The company has other platforms on which to build specialized, dynamic web applications. Sooner or later (or probably already) your company is going to need to develop content-oriented web applications and your WCMS is a logical place to start. However, these web applications are likely to introduce the most demanding and specialized requirements. It is quite possible that the union of your intranet and external website application requirements filter out every viable CMS — or at least force some painful compromises. If you have an alternative stack on which to build your fancy custom applications (possibly pulling content from your WCMS) and can let your WCMS focus on simple web publishing, you greatly increase the chance that you can comfortably support both internal and external publishing.
The corporate website and intranet are owned by one communications group. Today you may be able to align your intranet and external publishing needs; but will they stay aligned? How will you arbitrate between the competing priorities of the intranet and marketing website? What if those priorities don’t just compete for resources but actually conflict with each other? Things can get ugly when two different departments with different goals argue over what feature needs to be added next. These decisions get a lot easier if both the intranet and external website are owned by one communications group. Companies that are structured this way are usually small and can benefit the most from sharing the infrastructure cost between the intranet and extranet. Having the intranet owned by a communications group also pretty much ensures that criterion 1 is satisfied.

If your company meets these criteria, there is a good possibility that one instance of one CMS platform could serve you quite well. Otherwise, I would recommend doing one of your two projects and then putting the product that you used on the short list of products to consider for the other. If it turns out that the one platform supports the requirements of the second project, buy another instance of the software (hopefully at a discount) and start a new project to implement it. Take advantage of code and idea re-use but don’t let that constrain the flexibility and agility that you need to achieve your goals.

Posted in intranet, selection | 7 Comments »

The J. Boye Short List

Wednesday, August 12th, 2009

Today J. Boye posted a shortlist of vendors that “you should always consider” when selecting a web CMS. While many will take issue about what products were included or excluded from the list, what surprises me the most is that they published such a list at all. Here is why:

J. Boye is very closely partnered with CMS Watch, which covers 42 products in its Web Content Management Report. Putting out this list would seem to undercut CMS Watch’s flagship product.
The CMS Watch messaging has always been that there is no “magic quadrant” in CMS and I would tend to agree. J. Boye is the first reputable buy-side analyst to come out with one. The title “Web CMS Shortlist 2009″ suggests that they will come out with one every year.
J. Boye does a lot of CMS selection consulting. This list implies that their selection services will start from these 10 products. I think that undermines the value of their consulting services.

I am sure that the J. Boye website will get a lot of traffic from this post and there will be a lot of angry comments from the vendors and open source projects excluded from the list. Hey, all publicity is good publicity, right? It is very interesting to see what J. Boye considers to be “go to” products and what is a global footprint. But this list will not influence what products I consider during the CMS selections that I facilitate.

Posted in puzzling, selection | 4 Comments »

Dimensions of Success (or Ways to Fail)

Thursday, August 6th, 2009

While most of my consulting work is in product selection, I think the most interesting and rewarding type of project is evaluating the results of a CMS implementation. The typical scenario is that a client feels like their CMS project didn’t yield the expected results and engages Content Here to identify what went wrong and what adjustments should be made. Without this type of analysis, it is typical for a buyer to grumble and suffer with the solution for the next three or four years until they have the money to replace it; then the cycle repeats itself because nothing was learned from the experience.

When evaluating a CMS implementation, I typically look at three dimensions: expectations, product, and project.

Expectation rationality. Too many projects are doomed from the start because the expectations were set too high. It is often useful to have a third party assess whether the project was oversold or if it under-delivered.
Platform suitability. Choosing the wrong CMS product also puts the project in jeopardy. The platform should support your requirements, feel intuitive to your users, be maintainable by your team, and be supported by a well run company that can be a compatible partner.
Project execution. The project to implement the solution should be appropriately scoped and phased to achieve short term results quickly and work toward long term goals. You need to select a competent integration partner (internal or external) that you can trust and collaborate with to make good decisions. Your users need to be well supported with training and coaching.

Failure in any of these areas makes a buyer miserable but some are more correctable than others. Choosing the wrong product is the hardest mistake to undo. Migrations are always hard. Even if you can get the data over, all the work to customize and configure the wrong solution is non-transferable. However, it may be possible to minimize the impact through customizations and work-arounds. Generally, these systems are flexible enough to achieve some level of comfort even if it is not ideal.

Irrational expectations is the easiest problem to correct. For example, if it was unreasonable to expect that everyone in the organization (without training) would autonomously contribute their own content, maybe you need to keep that web coordinator role. Maybe some of the benefits will not be immediately realized after the first release of the solution. It is fairly typical to do a few subsequent maintenance releases to expose new functionality or correct bad design assumptions. Ideally, this should be a living solution that is constantly evolving and improving. You are not going to get everything right the first time.

Even though no implementations are perfect, some projects go better than others. Inexperience is the biggest culprit. You want to work with an integration team that is familiar with the technology (on most platforms, it usually takes 2 to 3 substantial projects to establish best practices and patterns). You also want to work with a team that has done similar scale projects, understands your industry, and can speak your language. It is easy to misinterpret requirements and make bad design assumptions if you don’t have a suitable context. Sometimes a rocky implementation with a new vendor is part of a natural learning process and things will improve. Other times, it is a sign that two organizations are incompatible as partners.

If your organization feels disillusioned by a recent CMS implementation, the good news is that most problems can be fixed without having to start over. All that is needed is a solid understanding of what went wrong and a roadmap of corrections. Over time, the solution will probably be able to achieve all of the reasonable expectations that you had for it. Let me know if you need help evaluating your CMS implementation. Content Here can put you on a path to improving it.

Posted in management, selection, usability | 1 Comment »

Fixed bid implementation work: a marriage made in Vegas

Monday, August 3rd, 2009

Most of my CMS selection clients are not just looking for software. They are looking for a solution that includes software and also a hefty dose of services to configure, customize, train, and support. Typically, once we have narrowed down to a short list of products, we start looking at systems integrators that can help develop the solution. A well-executed implementation and roll-out of a marginal product usually yields better business results than a train-wreck project to implement best-fit software. You need to work with a services organization (internal or external) that can partner with you to define and develop the solution that achieves your goals.

The other day, I was talking with a friend about projects gone bad and he asked me if I ever worked on a big fixed bid project that both client and supplier felt went very well. After considering all the projects that I worked on and the projects that I hear about as an analyst, I had to say no. There was always disappointment and frustration on either or both sides (usually both). But I was able to think of many iterative time and materials relationships that benefited both sides over years of working together. I have now been out of the systems integration business long enough to say, without any personal agenda, that fixed bid systems integration work is a failed enterprise.

The best analogy that I can make is that a fixed bid contract is like marrying someone you met at a craps table on a Las Vegas vacation. I am not saying that all spontaneous Vegas marriages fail, but they definitely have the odds stacked against them. Here is why; during the sales process, both sides get wrapped up in the deal and suppress rational doubts and concerns. They force themselves to believe everything is going to work out. They force decisions and assumptions that turn into a millstone hanging around the neck of the relationship.

The supplier talks himself into believing that he fully understands all the requirements and that every detail about his approach to solving them is accurate. That is simply impossible. No matter how long the pre-sales cycle lasts, it is impossible to fully understand every requirement and bring to light every latent expectation. The client doesn’t know what he wants until he sees what he doesn’t want. The initial estimate may have even been trimmed down because it “looked too big.” The client also assumes he fully understands the requirements and believes he is reasonably flexible about the design details. He trusts that the fixed bid contract ensures the delivery of the solution in his minds eye for the agreed upon price in the stated time frame.

After the deal is consummated, there is a short honeymoon phase where everyone seems to work together productively. This analysis phase goes smoothly because the stressful deadlines are far away and there are no concrete tests for progress. Sometimes a project can go through design without any awareness that it is horribly off course. That realization usually happens during the first development milestones when it is clear that the developer and client had significantly different understandings of the specification (if there even is one). Then things start to degrade very quickly. Both sides are stressed out and start to blame each other. Both parties feel like the other is being unreasonable. The contract that was supposed to protect everyone is turning into a handcuff connected to the most annoying person in the world. Both sides start looking for a way out.

Any successful partnership depends on both parties working collaboratively and creatively to solve problems as they come up. A fixed bid contract prevents this cooperation by making the relationship inflexible. But, you may ask, how much flexibility is realistic when a client has a limited budget and has promised a certain outcome of the project to company leadership and/or the customers? With a fixed bid contract, there is at least clear chain of blame. The business blames the project sponsor. The project sponsor blames the project manager. The project manager blames the consulting company. The consulting company blames the employees. The employees feel miserable and quality suffers. The contract provides unambiguous blaming instructions but it doesn’t solve the problem. The project is delayed and other costs will be realized.

A better strategy would be to partner with the supplier to jointly design and develop the optimal solution within those budget, time, and quality constraints. Achieving this kind of solution is an iterative/incremental process. The final solution will gradually materialize as options are explored and learning occurs (see Tracer Bullets). But this kind of cooperation requires a huge amount of trust and, sadly, very few business relationships enjoy much trust at all. Especially given the perceived track record of failed technology projects.

So, how do you achieve this level of trust? It takes time. Just like it helps to date before you get married, you want to start off with some small, low risk projects. Both sides need to believe that if they work at it, the relationship will last a long time and benefit them. There also needs to be transparency and equal rewards. The systems integrator needs to be transparent about their capabilities and experience and they cannot expect a huge windfall over a single project. The systems integrator should consume project resources (budget) as if they were his own. The client should expect to pay for what he gets and not try to trick the supplier into committing to unreasonable results. As Graham Oakes says, if you do not try to the make the relationship a win-win, you will probably wind up being the one who loses.

When you are buying services, you are really buying effort — not a result. A good project team will multiply the effort you purchased with skill and experience to deliver great things (maybe even better than you originally thought you wanted). The problem is, buyers are ill-equipped to gauge skill and experience. They feel more comfortable with the illusion that they are buying tangible results. Services companies that prefer to sell results rather than effort do so by charging a high risk premium (or “value pricing”) and having employees that can step up and overwork when the risk gamble is lost. So, the buyer is either overpaying or has hired an overworked team. Neither of theses options sounds particularly appealing.

If you do find yourself forced into asking for a fixed bid contract, do not assume that you can just set your calendar to the planned launch date and wait for the results. Instead, manage the project as actively as possible. Set up lots of intermediate milestones with exit criteria to test that the project is on track. If possible break up the project into multiple small fixed bid phases. For example, have a fixed bid design phase that ends with a prototype or semi-functional core of the application. Make sure that the design considers implementation budget as one of its requirements or constraints. Business owners: don’t let your staff get away with throwing the systems integrator under the bus when a project fails. Make them equally accountable for the outcome of the project. If the system integrator is underperforming you should learn of it one quarter of the way into the project; not within weeks of the planned launch date. Even better, don’t force your staff to come back with a fixed bid contract. Encourage the assembly of a high performing team of staff and consultants that maximizes the value of your budget.

Posted in commentary, development, selection | 3 Comments »

Code moves forward. Content moves backward.

Wednesday, July 1st, 2009

One of the primary functions of a web content management system is separating content from layout. Authors create semi-structured content in a display-neutral format and then the presentation templates transform that content to web pages for regular browsers, mobile browsers, RSS feeds, email, and print. As most readers of this blog know, this separation introduces big efficiencies in re-use: content is managed in one place and appears in many places and in many formats. But this magic does not come for free. Someone has to build presentation templates that render the content and that person needs to have developer skills. The template developer needs to know HTML and the special templating syntax to retrieve and format content from the repository. The developer also needs know how to test software for all the different conditions that it will encounter: different browsers; content with extreme values in any of its elements (like a really long title or a missing summary); and even high traffic load. Because one piece of code can potentially affect every page on the site, testing is important and it needs to be done in a safe place. The same thing goes for all sorts of other software configurations.

Essentially, the role of the static webmaster has been broken into two: the content contributors (that no longer need to be technical) and the developer (who needs to be more skilled than your average DreamWeaver jockey). It also breaks up the management of the site into two lifecycles: the content lifecycle and the code/configuration lifecycle. The production instance of the CMS itself is designed to support the content lifecycle. CMS have workflow functionality to manage the state of an asset from draft through published and to archived. They have preview functionality so that only contributors can see content that has not been published. Some CMS are designed sot that the development lifecycle can also occur in the production instance. This is usually done by creating workspaces or sandboxes — essentially treating code like another category of content. To be sure, you still want to have a QA instance of the system so you can test software upgrades (of the core) before applying them to your live site. In most CMS, however, developers work on separate environments (either individual developer environments and a code staging area or a shared development environment) and not the live, productive instance of the CMS.

While the content and the software lifecycles are de-coupled, they are interdependent. Developers need realistic content to develop and test code. The content relies on the code to define and display itself. There are lots of situations where these aspects get tangled. For example, when a new field is added to a content type it needs to be populated (sometimes manually) and the presentation templates need to be modified to display it. There are also cases where the line between content and code starts to blur: contributors style their content with CSS classes that are defined in style sheets; contributors can embed a tag that calls some additional display logic (like inserting a re-usable display component); contributors can build web forms that need to be submitted to code that does something with the information.

The standard approach for managing these interdependencies is what I call “code forward, content backward.” Content and configuration is developed in a development environment and tested in a QA environment. When it is ready, it is deployed to production. Content is developed and previewed in the production instance that contains the staging (or preview) and live content states. Periodically, content should be published backwards to the development and QA instances so that testing can be realistic as possible. In cases where the code/configuration and content are so tightly coupled (like when you need to break one field into two), you may need to export production content to the QA instance where you do some content transformation and test it with the newest code and then push that content and code back to production at the same time. When you do this, just make sure that you don’t have anyone adding content to production because it will be overwritten or (worse) cause some kind of corruption.

Different CMS handle the migration of code and content in different ways. Some provide nice graphical utilities to export configurations from instance of the application to another. In other products, there are ways to manually transfer the settings as a collection of files. Some products don’t support this at all so you have to manually repeat the same steps on each environment you are managing. When you are evaluating CMS products, keep these requirements in mind. Otherwise, you will be in for a surprise as you near the launch date of your new website and you need to fix bugs on live content.

Posted in architecture, selection | 10 Comments »