I. Introduction 

Project management has to be a core competency for an organization. I said IT projects but that is probably a bad term to use. What we really should be talking about is business projects with IT as an enabler. Research has shown that IT was not actually one of the more significant causes of problems with development projects. Research has shown that if projects are going to succeed one should really need to have a strong business possession, good project management practices and a focus on outcomes. In this regard there is a project management framework to provide a structure to the way of managing projects.

The post will first go through some of the reasons for needing a project management framework. I will then consider some of the key learning, both successes and failures. Finally I will describe a case study of the application of the project management framework.

The key message I will try to deliver is that you should have an agreed project management framework. This is not only to ensure that you have effective project management, but that it is done in a consistent way. You can then support your project management framework with training programs, guidelines and so forth. If everyone is doing it their own way it becomes much more difficult. I will be presenting the project framework, but I am not trying to sell that to you, what I am trying to sell to you is that it is important to have some form of project framework. And there is off the shelf software available that can assist project management. Microsoft Project, ACE Project are some of the examples, but there are many others that you might be able to fairly easily adapt for your own particular state of affairs.

II. The Project Management Framework 

Well why its required to implement a project management framework? There are situations in almost all IT organizations dealing with projects, where it have too many projects running over time and over budget. And there also are lots of creep in project scope and that is one of the reasons that they were running over time and over budget. Improper clarity in Project responsibility. Insufficient ownership by the business areas of projects. Insufficient emphasis on identifying risks and how they should be managed. And interestingly there are 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 is finished when the IT application has been developed.

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

And also we didn’t have a universal approach to project management. A lot of people did take project management seriously but they did it in their own way. I had been influenced by a Senior Project Manager who had 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.

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


1. Project Planning
2. Management of Risk
3. Management of Issues
4. Management of Change
5. Project Quality Check
6. Project Audit
7. Project Financial Management

1. 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.

2. Management of risk is extremely important. The first step is to identify what the considerable 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 alleviation strategies, ie 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 of it occurring so low you will 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 aren’t 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 doesn’t make sense to deal with them one by one as they occur. It would simply lead to anarchy. I guess some are so important you have to deal with them at the time and that is where judgment comes to play. But all issues should be recorded and it’s important to examine if there’s 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.

3. Management of change is another vital driver of project management. And this should be planned for early in the project rather than waiting until the commissioning stage. It really can be the key to success. We all know that change isn’t 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 organization that it is also in their long term interest if that is the case. If it’s not their long-term interest it’s 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/ re-skilling of course is a vitally important part of the management of change, particularly if staffs are changing responsibilities.

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

5. Project audit is an important variable. Many projects fail because the audit 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 the project down into chunks (manageable chunks). A good rule is not to allow any project phase to last more than six to twelve months or take up more than two to four staff years. Once you get beyond that, it’s 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 what is happening much more easily. However, you need to have a full understanding of the links between the different chunks. These have to be managed as well.

As to setting up the actual audit arrangements, this is horses for courses. The project management framework suggests that a project board be set up. And generally you should make the business area (the owner or end user of the project) 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, ie 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 audit 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 don’t 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 don’t proceed according to plan. It may be that as things develop the original plan doesn’t 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 part of the responsibility of the project board or whatever audit arrangements you establish.

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

Just to repeat something I said at the start of the post, I’m not arguing that you should follow the project management framework I had just discussed. I am just using it as an illustration of a framework and suggesting that something along these lines is important for all organizations. It is also important to have a framework for all projects whether IT enabled or not.



  1. Pingback: Software/Web Project Management | Think Tank

  2. Pingback: Project Systems | Think Tank

  3. Pingback: Planning | Think Tank

  4. Pingback: Project management best practices | Think Tank

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s