How to Plan a CMS Project - Project Success Factors

It may seem strange to define success. You'd think that delivering what the client wants on time and on budget would be considered success and it would, but there are other ways to achieve a successful outcome. Each client will have their own idea of success. One client may be willing to sacrifice features for a quicker delivery, another may be happy to extend the timeline to add in additional features. In both cases, the client gets what they want and the project is considered a success. In both cases, the project did not deliver on time, on budget with agreed functionality. This is where we need to start thinking outside the square.

The reality is that only 34% of projects are delivered on time and on budget (Standish Group Chaos Report, 2006); that's one in three! So the chances are your project is likely to run into problems of one type or another. That's just the way it is; even the best teams will run into trouble on projects, not because of their efforts but because of the clients changing their minds. Trying to fight this is foolish; the wise move is to establish upfront what success means to your client for their project. Once you understand that, you have something to work with, should issues arise during the project, or should I say when…

Success Factors

Working out what success means to your client for their project is a broad subject. Using the following success factors as a guide will make it easier for you to get a sense of what really matters to your client. It does become slightly more difficult when you have more than one client but I'll deal with that later.

The main success factors are listed below. They have been selected to deal with the obvious elements of the project, e.g. budget and timeline, as well as some of the less obvious factors such as quality and team satisfaction.

  • Have satisfied stakeholders

  • Meet the project's objectives/requirements

  • Meet an agreed budget

  • Deliver on time

  • Add value

  • Meet quality requirements

  • Sense of professional satisfaction for the team

Stakeholder Satisfaction

In many projects, there are a number of people who have a vested interest. Chances are your client will represent another management that they have to report to. There may be several departments involved in the project. On a recent project, although I only had one direct contact, that contact had to report to eight different stakeholders which meant every decision had to be considered in light of the eight stakeholders' view points. Clearly, a time consuming task.The important question is not what the stakeholders think but does it matter? Although there might be several stakeholders, do we need to take into account everyone's view?

Some stakeholders may be involved purely for political reasons and don't really matter when it comes to the project. So, the question here is do we have to make ALL of the stakeholders happy? That is, will the project still be considered a success if we make most, but not all of the stakeholders happy? If so, which stakeholders do we have to make sure we look after?

Another point to consider here is that it might not actually be possible to make all of the stakeholders happy; some may have opposing views. Some may simply be throwing their weight around because they can. If you are an external consultant then the internal politics aren't as important and you can focus on making the key stakeholders happy and not worrying about others. However, if you are managing an internal project, it might not be wise to upset stakeholders that you might need to deal with at a later date. The need for diplomacy is important, and the political landscape can have a large impact on how easy or difficult it will be to deliver the project.

These are the games that can be played in corporate situations that we want to avoid. It may be totally unrealistic to make all of the stakeholders happy. It may only matter to make one stakeholder happy, the one that is paying for the project; or perhaps it's the CEO. What matters is that you know who really matters.

These are difficult questions to ask, but they are very important and will make a difference to how you run the project and who's view point matters. In summary, the questions you want to ask are:

  • Do all the stakeholders have to be happy?

  • Is this actually possible?

  • If not which ones?

  • What are the risks of not making all the stakeholders happy?

Naturally, the answers to these questions and how you deal with them will differ depending on whether you are an external consultant or an internal project manager. For internal project managers, the long term impact of decisions made on this project need to be considered.

Meeting Project Objectives

Also stated in the Chaos Report quoted earlier was the staggering statistic that 45% of features built were never used and that only 20% of features were used often or always. That means that more than half of the work done on the project was for little benefit. It stands to reason then that for your project, there will be features that the client has requested that aren't going to be used. Of course, the difficult question to answer is which features they are. At this point, that's not the important question. At this point, the question that matters is whether everything in the requirements has to be delivered. If not, then you can use this later in the project to cut scope if you need to or trade a new feature for an original feature to keep the project on track. Many clients will ask for everything they can think of; that doesn't mean the project actually needs to deliver everything for the project to be considered a success. What's important here is for your client to appreciate that chances are, not everything they have asked for will be delivered. If you can achieve this, then you have a much greater chance of success.

In summary, the questions you want to ask are:

  • Do we have to deliver everything in the requirements?

  • If not which ones?

  • What happens if we don't?

  • What features really matter?

Although this is a very pragmatic view of which objectives are important, it's not always that easy for an internal project manager to be so clinical. The politics of internal organizations can color the decision-making process. In this case, the stakeholders are the clients and it's important to keep them happy. But, in reality, you can't always please everyone. Getting the stakeholders to make the decision can be a more effective political approach to shaping the project for success.

Meeting an Agreed Budget

From a sales perspective, the first thing you want to know is if the client has a budget and what the budget is. If you have a set budget, the goal is to work out what you can deliver for that budget and make the client happy that they got a good deal. However, there are times when the budget isn't large enough for the features required. If that's the case, then there are only two options:

  1. Increase budget

  2. Cut scope

Note, there really are only two options; getting people to work more hours is actually increasing the budget but hiding it in overtime. The question of budget is probably the most important. If you can't shift the budget, then you go back to the previous success factor—meeting project objectives and ask the client what they are willing to sacrifice to stay within budget. It can be quite confronting to ask such questions and could put both you and your and client in an awkward position. I make no apologies for this; effective project management is a difficult task. It's much better to deal with these issues upfront than later down the track when the client insists on all features within budget when it's not possible without you losing money on the job. In any project, there are three variables that can be adjusted: scope, timing, and budget. You need to know which of these are most important to the client and which ones you can move on.

In regards to budget, the questions you want to ask are:

  • Is there a set budget?

  • What happens if we go over budget?

  • If we can't go over budget is there anything we can cut from the scope?

Delivering On Time

The last of the variables is time. Apparently, time heals all wounds; but it can cause havoc on a project if not managed appropriately. What you need to know is firstly, if there is a deadline, and by deadline I mean a hard deadline, not one that has arbitrarily been chosen by the client because they would like it by that time. If there is a deadline, the next question is whether the deadline is a soft or hard deadline. In reality, there is no such thing as a hard deadline; what you're looking for here is whether the deadline has dependencies that will cause issues if it's not met. E.g., the launch of the new website has already been announced to the media. That's sort of difficult to get around; not impossible but potentially embarrassing for your client.

So, first we need to establish if there is a deadline, second if it's fixed. If the deadline is fixed, you can then go back to the previous success factors to see if the client is willing to budge on what features are delivered or if they are willing to adjust the budget to get more resources onboard. The idea here is to reinforce to the client that they might not be able to get everything on time and on budget and because of that they may need to make some compromises. What you are trying to work out is where your client is willing to compromise; what matters to them most, is it features, budget, or time? Having all the features is not an issue if the client is willing to increase the budget or timeline. Meeting a fixed deadline is fine if you can cut the number of features being delivered. The key here is understanding what matters most to the client.

Note: If the client is not willing to compromise at all, the project risk will increase; the odds are that only 34% of projects will be delivered on time, on budget with agreed functionality. The question is whether you feel confident enough that your project will fall into that 34%.

In summary, the questions you want to ask are:

  • Is there a deadline?

  • Is the deadline fixed?

  • If the deadline is fixed, is there anything in the scope we can cut?

  • What happens if we don't meet the deadline?

Adding Value

So far, we have talked about the obvious elements of projects; adding value to the business isn't as obvious. We may not have even asked this question of the client and they may not have asked it of themselves. It may be the case that someone higher up has dictated that the project goes ahead, the reasons for which are not fully understood. And it may not matter; what you need to know is if that's the case. What this means is that you need to understand if the project actually has to add value to the business i.e. achieve a particular outcome for the business. If so, what happens if the outcome is not delivered? Will that cause a significant problem? E.g., loss of revenue? In the case of content management projects, the success of the project is dependent on the people that manage the content; if they aren't appropriately trained and capable of managing the content, it will affect the business outcomes. Perhaps it doesn't matter for this particular project as it's a political project or a trial project, but if it does matter, you need to know so that you can put appropriate measures in place—such as training, to make sure the project adds the value expected. It's a fundamental part of projects that is easily missed in the details of the project.

The key questions to ask are:

  • Will the project deliver value to the business?

  • Does this matter?

  • If not, what is the reason for the project?

Meeting Quality Requirements

Quality can seem like an intangible aspect of a project; what's quality to one person is mediocre to another. That's fine; the goal is to understand what your client considers to be quality and how much it matters to them. For instance, you may be able to deliver the project on time but without ensuring cross-browser compatibility. This is something that I consider to be important; your client may not care if it works in the most popular browsers. Meeting minimum accessibility standards may be considered a mandatory feature, or not, depending on what matters to your client. That's what needs to be established; is there a standard that has to be reached and in a worse case scenario, what would happen if it wasn't reached? Would the client be open to legal action or potentially lose revenue? Knowing the quality requirements will help you to shape the features, budget, and timeline to ensure the project is a success.

The key questions to ask are:

  • Is there a standard we have to reach?

  • What is that standard?

  • Does it matter if we don't reach it?

Team Satisfaction

The idea of team satisfaction is something that is rarely raised. Why would the client care if the team is satisfied? Isn't the goal to make sure the client is satisfied? Well, yes, but if the team is not happy, then it makes it much harder to deliver. A recent study rated "trust" as the most important factor in successful technical teams. If your team is not happy and don't trust each other, it's going to be a hell of a lot harder to deliver what the client wants. It's also important for the client to understand that they have a vested interest in keeping the team happy because it will mean better results for them. If they don't care about the team, then what happens after the project is delivered and there's a need for maintenance and support? How supportive are the team likely to be if they were pushed to work long hours to deliver in the first place and got no appreciation for that? Every time I've posed this question to a client, they have changed their viewpoint from not caring to making it one of the success factors of the project.

The questions to ask your client are:

  • Do we care about the team?

  • Do we mind if they have to work long hours?

  • Do we mind if they aren't happy with the result?

  • Will we need team members for ongoing support?

Success Sliders

Now that we know what all the success factors are, we need to get the client to rate them. It's an arbitrary rating system designed to establish the relative importance of each factor. What you need to do is: for each success factor find out how important it is on a scale of one to four. (Note: we use 1 to 4 so that we don't have a whole stack of features in the middle; if we used 1 to 5, it would be too easy for clients to pick the middle option, this way, they have to decide which side of the line the success factor sits.)

Example Success Sliders

Meet the Budget Given the project has had to raise significant funding and withstand political pressure to make this a commercial project, there is no room to move onthe budget. Rating: 4

Deliver on Time The initial deadline was March this year but due to funding issues, this was not possible. Now the deadline is flexible, the sooner the better, but if delivered in January 08 rather than Nov 07, it wouldn’t be a major issue. Rating: 1

Add Value The entire purpose of the project is to provide a higher level of business infrastructure, therefore it is very important that the solution adds significant value to the business. Rating: 3

Meet Quality Level The solution has to work, it must be functional. However, it's not necessary that it is the most elegant and well designed solution. It is more a business tool that a marketing device. Rating: 2

Team Satisfaction We realized that it was important that the entire team was happy with the way things progressed as this will be a long term relationship that needs to last beyond the delivery of this project. However, there was a sense of realism that given the constraints of the project, there might be some need for compromise along the way. Rating: 3

By using a visual sliding scale to represent the ratings given to each success factor, we can very quickly see what the client cares about the most. In the diagram below, it's easy to see the budget is by far the most important factor, and deadline is the least important. So, the project can be delivered late and with some movement in scope but it cannot go over budget. With team satisfaction, it was important for the client to acknowledge that after the project was completed, there would be an ongoing need for further development down the track so it was important that the team were happy with the outcomes so that they would be willing to work on future enhancements.