fork in the road
No one likes going through the procurement process, so use these tips to make sure you get it right the first time PHOTO: bradhoc

Selecting the right technology is a daunting prospect. No one likes going through the procurement process, so people are understandably looking for any advice to help them make their decision.

Deane Barker's book "Web Content Management" includes a chapter on acquiring a CMS. Tony Byrne and Jarrod Gingras of the Real Story Group recently published a new book which focuses entirely on the technology selection process, titled (appropriately enough), "The Right Way to Select Technology." All three have years of experience and provide clear advice. 

The one piece of advice all three share which resonates with the mistakes and successes I regularly see is this: focus on the problem at hand, not on everything that can be done.

Tech Procurement's Chicken and Egg Problem

One thing that frequently comes up in the procurement stage is organizations saying they need Feature X. Too often, the need for that feature is driven by the belief that the feature will solve Problem X. 

That seems logical until further analysis determines Problem X is really just a symptom of a larger, systemic issue in the organization.

Solving Problem X with Feature X is like taking cough medicine to solve a hacking cough. What you really need is to go see a doctor so she can prescribe antibiotics for your pneumonia.

When in doubt, ask questions. Why is a problem occurring? What factors have led to the occurrence? How did this issue first materialize?

Having an external party come into your organization to determine this usually pays dividends. Like a doctor, they can bring their experience dealing with similar situations. They can help define the problems that need to be fixed and an appropriate solution to match.

Use Cases Put Solution Before Technology

A good way to work through the problem is to start with use cases. What do you need to accomplish? Who needs to participate? What are the end goals? The goal is not how, but what. This helps to separate what needs to be done from Feature X.

So many people miss this key concept. You are not buying a CMS or a community platform. You are buying a solution to the problem of managing your internet presence. How that solution solves the problem can vary.

Sure, if you are trying to solve a website problem, a CMS is likely involved. The use cases can refer to a CMS as a repository and publisher. Just avoid specifying how the CMS accomplishes the task.

For example, if you need to publish content provided from authors external to your organization, you might outline the following steps:

  • Author emails article in a Word document to an editor
  • Editor saves it into Google Drive
  • Editor cuts-and-pastes the article into the CMS
  • Editor edits the document, communicating with author over email for any clarifications
  • Senior editor provides secondary review
  • The CMS publishes the article.

That’s fine but it is a lacking in many ways. It specifies how. A better approach would be:

  • Author submits an article to the organization for publishing. Each of the X editors will receive content from Y authors every week and double that the last week of the month
  • Editor will edit content as necessary
  • The editor completes the edits and communicates with the author regarding the changes
  • Once ready, a final approver checks over the article prior to publishing it
  • The article is published from the CMS to the website on the scheduled date and time.

You perform this process according to the first description. Alternatively, there could be some built-in collaboration with the author. Perhaps a preview link can be shared to non-users of the system. The editing could happen internally or externally. A lot depends on the deeper requirements regarding auditing, control and system access.

Don't Get Caught Up in Software Features Bling

A lot of features are out there. You don’t need them all.

Base your decision solely on the use cases outlined above. Every system will address those needs differently and will provide some additional little features to make things easier.

Sure, a lot of the advanced features out there would be cool to implement. However, unless that feature is part of your next funded project, don’t be lured to buy a more expensive product with more features. Focus on your current needs.

Make Your Software Selection Count

Share your use cases with the vendors and demand to see them in action. Don’t settle on a recorded demo. Make sure it is live and ask questions. The vendor will try and script things as much as possible. The more spontaneous and driven by live feedback the demo is, the more likely the product will work as advertised.

Insist on seeing your use cases demonstrated. Have the vendor show them first. All the extras can wait until the end. Do not forget to ask about cost. That fancy reporting module may be nice, but it can cost a fortune.

At the end of the day, it is your system, not the vendor’s. You will have to live with the outcome of the purchase. That means your core needs need to be met. You don’t want to do this again in a couple of years because you never addressed the underlying issues with Problem X.