Technology before requirements
I have been presenting at several conferences in the past couple of weeks (10 sessions in two weeks) and I am still getting the same situation over and over again. I had an attendee in a workshop on a content management maturity model say: "I am not sure where to start. It feels like this is so overwhelming. Can't we buy the tool first? That's what my boss wants me to do." I can understand why this is a first reaction to the complexity of content management. There are so many issues and factors to consider. From business problems to content architecture, existing systems that require migration and integration, user needs and scenarios, meta-data standards, taxonomy development, work-flow processes, governance, change management and so on. The first time you are going through this, it is overwhelming. But choosing a tool before understanding exactly what you need can create at least three major problems:
1. Taking the tool vendors process and trying to make it your own. This seems to be the 'easy' way out, but it is a mistake. The vendor does not know your business (even if they work solely in your industry, organizations and their systems and work practices are very different and one process will not fit all.) The processes that their tool supports either out of the box or with some customization will have a small chance of exactly meeting your requirements. Seemingly simple things like work-flow can be disastrously inappropriate for your organization when it comes time to implement. By first understanding the nature of your user needs and content life-cycles you can choose a tool that is appropriate for what you need to accomplish.
2. Getting seduced by features and functions. Lots of things look clever and interesting that have no bearing on your business. These slick demos can distract you from your goal and take you down the wrong path
3. Limitations of technology that prevent you from presenting information as your customers need it. We just ran into this with a client. The core premise around how content would be assembled for consumption had to be rethought since the tool had serious limitations regarding the way in which content could be dynamically presented.
There are many other issues that can crop up by putting the technology cart before the requirements horse, but they are variations on these major themes. For example, by falling into trap number 1, you will naturally short circuit the requirements process and make major assumptions (usually incorrect) about your users and their needs. Trap 2 will lead to rolling out sexy functions that no one needs or uses. Trap 3 will cause you not to consider what is possible and most helpful to the business, but instead focus on what can be developed with the tool in a limited time frame. The goal becomes finishing and deploying the tool rather than solving problems, and so on.
In a nut shell, you need to first understand and validate what is important to the organization and its business users and then build out detailed specifications based on those needs and priorities. Then you can go about the selection process without falling into these traps.