Software development, as an industry, has been around for over 40 years. Web development has been around for a little over 10 years, content management has really only emerged in the last 5 years as an industry in its own right. The question is, how does that affect the way we manage CM projects? The best way to understand this is to look at the differences between traditional development and content management. Through the differences, we will be able to see how best to approach content management projects as a discipline in their own right.
In traditional development, there are many established methods to choose from. There are dozens of books that you can read and courses you can attend to learn how to manage projects. In the early days of web development, the prevailing mindset was that the rules of traditional development didn't apply; it was a new world and needed a new way of doing things. This was akin to throwing the baby out with the bath water. Sure, web development was different from traditional development, but not so much that the rule book needed to be re written. It did need to be adapted to the new environment but not totally ignored. The result was that many people in web development simply made it up as they went along. Now that content management has emerged, there's a chance that a similar mindset could emerge and the lessons still being learned in web development and long since learned in traditional development will be once again be ignored. This would be a big mistake. That's not to say you can copy an approach from traditional or web development to content management, but there is much that can be adapted.
So, what makes content management different? Why can't we simply pick a known and documented process for software development and use that? The main reason is that there are elements to a content management project that aren't covered in existing processes. Therefore, we need to be aware of the differences, so that when we select a process, we know what it covers and what we have to adjust for a content management project.
To start with, let's look at example of a traditional project versus a content management project. To do this, I'm going to use cricket as an example. For those of you not familiar with cricket, you can substitute football or any sport you like.
A game of test cricket is played over a period of five days on an oval. Each team gets two opportunities to score as many runs as they can. A team is made up of 11 players, each with their speciality. Most players are either a batter or bowler. One player is the wicket keeper (for football fans, substitute strikers, defenders, and goalie). The positions each player takes on the ground and the role they play is well established. There are traditional game plans. The rules are well known (and debated at times) with official adjudication by professional referees (who still manage to make bad decisions!).
Test cricket is a well known, accepted, and understood game. The rules and strategies have been established over time and although they have evolved, the basics are the same.
20–20 cricket is a new version of cricket. It's played on the same ground, but each team only gets 20 overs each to score as many runs as they can. The game takes less than half a day and has a far quicker and more intensive pace than test cricket. The strategies for 20–20 are different from test cricket even though it's based on the same game. Similarly, we are used to traditional software projects lasting years but content management projects are expected to be completed in as little as a month (depending on the scale of the project).
So, what we have here are sports based on the same game. But each has its elements that are unique and require a specific approach. The same goes with traditional projects and content management projects. Both are projects and the basic principles apply, but the approach taken will differ depending on the type of project. Test cricketers won't necessarily make good 20–20 cricket players and vice versa. Assuming a project manager used to traditional development will be suitable for content management is being short sighted. What is important is to understand the role being played and having the right person to play that role.
If we look into the key differences between traditional projects and content management projects, it's easier to see why we need to be careful about how we approach content management projects.
As mentioned previously, the approach to implementing a content management system is not the same as a traditional software development process. Unfortunately, there are no defined methodologies for content management, because the industry is still taking form. In essence, we are working it out along the way through trial and error. The reason that no methodologies exist is that content management brings together a range of disciplines that have never been combined before. Therefore, we have to look at existing methodologies for each discipline and adapt them to content management project, and where there are no existing practices, form new ones.
So, we can't rely on a tried and trusted approach because there simply aren't any. Part of what this book is trying to achieve is to define a set of practices that will help Project Managers to deal with content management projects until the industry matures enough and methodologies emerge.
One of the major challenges in content management projects is the wide range of stakeholders that are involved. For a traditional application, you would expect the business owner/manager to be the key stakeholder, as well as including other people or departments that are to use the application or will be affected by it. The application may never need to involve marketing, public relations, communications departments, etc. In content management projects that are public facing, the number of stakeholders can be far greater as the end result will affect many departments in a company.
For example, a car parts manufacturer might build an application that allows its suppliers to look up information on the parts that it sells. This could be a simple database that is provided to the suppliers on a CD-ROM. Chances are that the marketing department and public relations would have little involvement as this is a business-to-business style solution and is a tool to help the supplier. The public would be unlikely to get access to such an application. However, if the same functionality was to be supplied via a website, it's highly likely that the look and feel of the information would have to fall within corporate style guides. If the information was highly technical, it could require restricted access so that only suppliers would be able to access that information. This would require the establishment of user accounts and management of those accounts that would not be required for the CD-ROM distributed once every 12 months. There would also be considerations regarding the upkeep of the information, which would impact on who manages that content internally. Suddenly, what was a straightforward task of supplying product information via CD-ROM becomes a more complex process when done via a content management system as more stakeholders are involved in websites than traditional applications, especially when the information is public facing.
This is a major problem when it comes to content management projects. It's not hard to find people who have been working on software or web projects for 10 or more years. When it comes to content management, it's hard to find someone with more than a few years experience. When it comes to eZ publish, it's only been around since 1999, so the most experienced people are likely to have a maximum of seven years working with it. The reality is, finding experienced eZ publish developers is difficult and most will need to be trained. Becoming proficient in eZ publish takes at least three months of development work after having been trained. Doing sophisticated work with extensions and integration is something that should be left to developers with over a year's experience.
In terms of the other roles played on eZ publish projects, experience with the technology is less important, but experience with content management is very important. Once again, these people are hard to find. Because of this, the people that end up working on content management projects rarely have the right experience. It's not a question of ability, it's simply one of training. There are no established training courses or methodologies for content management. We are making things up as we go along.
The people that are drawn to content management tend to have varied backgrounds. Some with experience in web development, some with information management, some with writing and documentation; but very few have an understanding of all elements. There are very few courses dedicated to content management. It's a new field and we are finding our way in what works and what doesn't. It's going to take time for the industry to become better established and the necessary skills better understood. Until that point, all we can do is cut our teeth on projects, learn from our mistakes, and hopefully, make fewer mistakes on the next project.
The other difference between content management and traditional projects is the breadth of skills required. Content itself is something that web developers have had to deal with, but not to the same level as required in content management. It works in a different way. It also combines workflow, business processes, and data manipulation. These elements are well understood in traditional development, so getting people with that sort of experience can help. But chances are, they won't be used to the limitations of a web browser as the client interface.
No matter how you look at it, staffing content management projects will continue to be a challenge until the industry has matured enough to have established practices and people, able to study what's involved before working on their first project. In the meanwhile, projects will continue to suffer from inexperienced or inappropriate staff.
Web projects can be quite small, lasting a week or two. Content management projects tend to be larger but still can vary in size quite significantly. A simple installation of eZ publish with minimal customization can be done in under a week. Larger jobs can take over a year from start to finish. It stands to reason, then, that the approach taken for smaller jobs would be different from larger jobs. As a rule of thumb, the bigger the project, the more rigour and discipline required. Basically, there is no one-size-fits all approach. For each project, the approach needs to be tailored to fit the particular needs of that project.
Having a client that understands what they are truly asking for is a blessing. It's also extremely rare. But we can't simply blame the client. As professionals, it's our job to explain things to the client, so that they do have an understanding. In the early days of the Web, it felt like half of the time was spent explaining to clients how a website worked. Nowadays, most people get the basics. Not so with content management, however. There is still a poor understanding of how these systems work and how best to implement them to achieve business objectives.
Another problem is that the use of the Web as a business tool is also changing at a rapid rate. The way we interact with websites is changing, the expectations of the users are increasing, and how things will pan out, no one knows—although if you are willing to part with significant amounts of cash, I'm sure there are plenty of research companies out there that are willing to take a guess at what will happen!
But mostly, it comes down to the client knowing what they want. I can't tell you how many times I'm asked, "Tell me what it can do and I'll tell you what I want". My standard response is "Tell me what you hope to achieve and I'll tell you how we can make it happen". It's too easy to focus on the features and ignore the business objectives. If a project doesn't have clear objectives, how can we tell if the solution implemented has succeeded?
In eZ publish projects, we are mostly dealing with web browsers. But one of the key benefits of eZ publish is its separation of presentation from content so that you can output to other formats and devices, e.g. XML, RSS, RFT, wireless devices, etc. Not only that, there are new devices emerging and we don't know what the future will hold.