A picture paints a thousand words, a demo easily paints a thousand pictures, especially when it comes to a web content management system.

Working With Different Expectations

The life of a CMS system vendor is fraught with pitfalls and problems. I have previously discussed the changing role of the business analyst and the challenges faced when gathering requirements here on CMSWire. But the project lifecycle is much broader than simply defining the problem space.

Projects typically start with a sales process, post requirement gathering there is a project implementation phase, then testing and so on. Each of these steps can be a mini project in its own right, and at every turn the client has certain expectations. And it is these expectations that can cause problems.

‘Misaligned expectations’ are surely one of the single biggest reasons for the failure of CMS and similar projects. Put simply, the client expects one thing, the vendor delivers another and a problem occurs. Often, it can work the other way round. The vendor expects a certain level of service from the client, which they fail to deliver, causing frustrations within the project.

Expectations are set in many ways throughout a project. A sales leaflet can start the process, a demo continues it, sales patter and case studies may raise expectations upwards. Clients can also set their own expectations, and internal project teams can mold and alter each others.

There is no single way to address all of these problems. But there is an effective way to address one single category of ‘misaligned expectations’ -- a category that accounts for a large percentage of the overall issues. And, it deals with the technology.

Technology Expectations

Expectations of technology, be they too high or too low, account for the majority of issues on these types of projects. Clients generally don’t understand the technology they are buying. Why would they? They just want a system that works in a way that makes sense to them.

Vendors have a system, which generally works one way but can be modified in some respect to accommodate its user base. So, you have a client with preconceived ideas and a platform that is pretty much designed to work one way only. Left alone, this situation can cause issues. So what is the answer?

A Demo Goes a Long Way

It is simple really. Demo the product. A lot. Demo it every chance you get throughout the project lifecycle. In fact, if you don’t have your CMS system pre-configured on a virtual machine or test site, ready to view by a client any time, then you are putting your projects at risk unnecessarily.

Putting the product in front of the user at every available opportunity is the single most important thing you can do on a project to align expectations. Product demos are very low cost, especially when compared to expensive reworks further down the line. They are also easy to insert into your existing project methodology.

  • The Sales Process: Give sales people a virtual machine to run on their laptops and tell them to get the product out as often as possible. Less technical sales teams should be accompanied by a product expert if required. Clients will feel much more engaged if they are seeing the real product right from the start.
  • Requirements Gathering: This is slightly trickier, as you are trying to understand the problem, not define the solution. But why not have a test site up on the big screen just in case you can use it? If users start to describe features, point them at the screen -- “A little bit like this you mean?”
  • Implementation: You should be reviewing code releases with the client regularly anyway. Make sure you do it face to face, and early on. Get the clients specific implementation in front of them as soon as possible, and make sure you run them through the system the first time personally. First impressions will count for a lot.

Top 5 Tips For Demoing Your Product

  1. Don’t take brochures or paper materials to sales meetings. Take a demo instead.
  2. Put a virtual machine on a memory stick and take it everywhere with you. You might not always be able to use it, but be prepared
  3. Have a vanilla version, and a customized version, of your CMS to demonstrate the differences.
  4. If at any point during the project you find yourself talking to a client about a feature, get the site out and show it live.
  5. Always demo the system face to face if you can. Over the telephone isn’t nearly as effective, and Skype even less so.