How to Plan a CMS Project - Quality

What is quality? Is it 99% uptime? Is it a high quality visual design? Is it quick response times? Is it ease of use? Is it security? Or all of the above.We have already mentioned quality when looking at success factors but because of its importance, it's worth reviewing in its own right.

Quality is an intangible feature that, like visual design, can be very subjective and very different for each person. In fact, discussing quality tends to raise more debates for clients than most other success factors.

We all have our own internal measure of quality, but rarely do we state this explicitly, usually it's learned through trial and error. We show the client a result, they tell us it's not good enough and why. We fix that, re-present the solution and the client identifies another issue, and so on and so on. To save some of this grief, it's handy to have explicitly stated what the quality requirements for this project are.

When it comes to the individual quality factors, most of them are satisfied by eZ publish, so what we need to consider is the solution that we are creating on top of the eZ publish framework.

Quality Factors

Conformity Does the solution have all the data, processes or functionality specified?

Useability Is the solution easy to use and understand from the client's perspective?

Efficiency Does the solution use the people, business process, hardware, software efficiently?

Maintainability Is the solution easy to maintain and support?

Reliability Does the solution perform reliably and is it free of errors?

Portability Does the solution work properly in different environments (e.g. browsers, operating systems)?

Reusability Does the solution require reuse or extension for a different purpose or application?

Security Is the solution secure from unauthorized access and modification? Auditability Is it easily audited and is there sufficient reporting?

Measuring Quality

The key is what the client considers to be quality. We use the same rating system as we did for success factors, 1 to 4 (4 being the highest).

The initial reaction of clients is that everything should be of high quality. Then, when you look at each individual factor you'll find more reason surfacing. If you have a number of people representing your client, a good test is to get them to do individual ratings and compare to see the different views and work out a consensus. Normally, someone from IT will give maintainability high, someone from client service would put usability high. Both are important, but which is more? If you get high ratings for everything, then you have a potentially unrealistic project with a high risk factor. Of course, everything is possible with enough time or money. What sometimes happens is a factor that hasn't surfaced to date emerges and affects the project significantly; it could be that security is of high importance, or reliability as the solution will be the main interface to clients and must be stable. All of this will influence how the solution is designed so it's good to have this clear upfront. It may already be stated in the requirements but going over it again and getting a rating will give you a better context as to the relative importance of that particular factor.

Remember, the client has already given you a rating for quality in the success factors so anything here needs to be considered in light of that rating. The goal here again is to understand what matters to the client and have it stated explicitly so everyone is on the same page.

The following table is an example from a recent project. What stood out as most important was usability of the end result. This particular project was for internal use so the client was happy to dictate which browser to use so portability didn't matter.