Why did the ABS implement a project management framework? There was a situation about eight years ago where we had too many projects running over time and over budget. And there also was a lot of creep in project scope and that’s one of the reasons that they were running over time and over budget. Project responsibility was not always clear. There was insufficient ownership by the business areas of projects. There was also insufficient emphasis on identifying risks and how they should be managed. And, interestingly, we found there was too much emphasis on output rather than outcomes. This is quite common for projects that are based on new IT applications. There is a tendency to think the job was finished when the IT application had been developed.

Just to give you one example of the emphasis on outputs rather than outcomes, we had a major data warehouse project where the people that developed it said, 'it is built, it meets all the specifications and is fully tested”. But the end users were not using it effectively. So the project was not really complete. There was a missing gap between the output of delivering a particular warehouse system and the outcome it being used successfully by the people who should be using it. And I think this is true of a lot of projects. People forget about the last step of assisting users to apply the new system effectively.

And also we did not have a universal approach to project management. A lot of people did take project management seriously but they did it in their own way. We were influenced by a representative of Lend Lease, a company that has a great reputation for project management. In fact they argue that good project management is one of the most significant contributors to their profit margins. At the time they were constructing a new building for us so we had an opportunity to talk to some of their senior people and project management was one of the issues that we talked about.

Our project management framework has seven key elements. These are set out in Table 1. It is not rocket science, but a lot of common sense. But actually having the elements documented and used to manage projects is very sensible.

The first phase I will talk about is project planning. This phase sets out the business case including the specification of outcomes that you actually want to achieve. But also, importantly, it defines measures that determine whether you actually met these outcomes or not. It also sets out the project outputs and how they are linked to the project outcomes.

Management of risk is extremely important. The first step is to identify what the significant risks are and this really should be done in a brainstorming type of session. And sometimes it is very useful to bring in people who are not too closely associated with the project. You might bring in people who may not know much about the particular project but they have experience in project management and through this set of eyes they can see things that often those that are closer to the project cannot see. After you have identified the risk it is important to develop risk mitigation strategies, i.e. how might you reduce or even eliminate a risk. And then you have to make a decision on whether you will adopt the risk mitigation strategy or take the risk. In some cases its impact may be so low or the chance so low you decide, well let us take the risk and not expend the resources involved in reducing the risk. It is also an important part of project management to think about what the contingency plans will be where you are not fully taking account of a risk. And of course it is important to monitor risks all the way through the project. They can change.

We all know from our experience that issues crop up all the time. They need to be managed but it does not make sense to deal with them one by one as they occur. It would simply lead to chaos. I guess some are so important you have to and that is where judgement comes to play. But all issues should be recorded and it is important to examine if there are some patterns emerging so that you can address issues in a systemic way rather than just on a one by one ad-hoc way. And as issues are processed they become either tasks or risks or dropped as no longer an issue because they are not sufficiently important.

Management of change is another key part of project management. And this should be planned for early in the project rather than waiting until the commissioning stage, because it really can be the key to success. We all know that change is not always welcome by those who are most affected. A lot of people prefer to live in their comfort zone. So it is important to identify the people who might be affected by change, understand what their concerns are and develop plans to address these concerns. It is also important to win their hearts and minds and that they know and understand why you are making change. You need to convince people that it is not only in the long term interest of the organisation that it is also in their long term interest if that is the case. If it is not their long-term interest it is better that they know that sooner rather than later as well. It helps them plan their future. Job design is a very important part of this process. And if you can, you should allow the people who are most affected to influence the way jobs are designed. And training or reskilling of course is a vitally important part of the management of change, particularly if staff are changing responsibilities.

Project quality is largely common sense. For your outputs, determine how you are going to decide whether they are actually fit for purpose. What are the measures of success?

Project governance is important. Many projects fail because the governance arrangements are inappropriate or unclear. First of all, establish milestones and manageable project phases. A lot of projects are very big so it is important to break them down into chunks, manageable chunks. We have a rule that we do not allow any project phase to last more than 12 months or take up more than four staff years. Once you get beyond that, it is starting to get difficult to manage. Of course lots of large projects are much bigger than that. So you should try and break it down into manageable chunks that you can control much more easily, as well as being able to gain a full understanding of the links between the different chunks. These have to be managed as well.

As to setting up the actual governance arrangements, this is ‘horses for courses’. Our project management framework suggests that a project board be set up. And generally you should make the business area provide the chair of the project board just to make sure the project ownership is appropriate and senior people from the business area are involved throughout the project. For smaller projects this might be overkill and the usual line manager, if you like, can take on the responsibility of the project board, i.e. the decision making responsibility: determining key strategies, monitoring project progress and so forth. But they may decide to set up a consultative or steering group to assist them even though they are taking the main responsibility. But no matter what the project governance arrangements are it is important to define and document the roles and responsibilities of all who are involved or confusion can reign. People can start getting involved in activities that are not really their business. Or the reverse can occur, that is they do not take responsibility for things that they really should be responsible for. The key role is the project manager. That is the person who has most responsibility for the things that happen from day to day. And the project owner is important. They often are the Chair of the Project Board or they may delegate their authority to someone else. But they must retain ownership.

It is necessary to make hard decisions that may change original project plans if things do not proceed according to plan. It may be that as things develop the original plan does not make sense anymore, that you should do something somewhat different. You may have budget blowouts or time table blowouts perhaps even in the early phases of the project. And making necessary adjustments to the project plan is a very important plan of the responsibility of the project board or whatever governance arrangements you establish. We try very hard to maintain budgets and timetables no matter what. So, if things are not going according to plan the preferred option is to modify our ambitions rather than just let things slip.

I will not say much about the project financial management except that it is largely common sense. We have found it useful to analyse variations to expenditure plans, particularly significant variations, because it can give you insights into potential problems.

Within our project management framework, there is a set of facilities that are part of the framework. First of all there is a software package. We have developed our own package within the Lotus Notes system. To support the package there are a range of templates (e.g. Issues Management, Risk Management) and Guidelines. And there are also support arrangements inside the ABS, experts on project management that people can talk to particularly in the early stages of a project but also in the intermediate and later stages if problems emerge. We have also contracted an external expert, a chap by the name of John Smyrk who helps us from time to time, particularly in the early stages of large projects. And the suite of tools is supported by classroom training and an online training package.

Just repeating something I said at the start of the talk, I am not arguing that you should use the ABS project management framework, I am just using it as an illustration of a framework and suggesting that something along these lines is important for all organisations. It is also important for all projects whether IT enabled or not.