Project Management Software
Specialists in Project Infrastructure
Aside from the commercially available methodologies such as Prince 2 and Rational Unified Process, there are many methodology developed to suit individual organisations. This white paper sets out to provide a better understanding of methodologies, and how they can be developed and implemented.
Project Management Methodology v Application Development Methodology
You will notice there is nothing mentioned about requirements or testing or vendor selection. That is part of an Applications Development Methodology or Software Development Methodology.
Distinction between Methodologies
The project management methodology is the framework. An applications development methodology is the meat on the bones. The true test of what is a project management methodology, is to ask the question
"Could you put other meat on the same bones?"
For example, you might have a package selection methodology which could plug into the project management methodology and fit just as well. The difference is that it is a different set of activities, roles, responsibilities, risks, etc.
Why Is It Important To Draw the Distinction
It is important because any organisation should have a consistent project management methodology in place which is common to all types of project. In this way, people can move comfortably from applications development, to infrastructure roll out, to software selection to even relocating to new buildings using the same approach.
Training people in project management can take place prior to them learning how to do a development, or select software or even to do some ad hoc project that does not have a defined methodology. People need to know they should manage scope, and how to do it. They need to know how to set up a budget and manage it. They need to know how to do a risk assessment and manage risks.
A Methodology is not a Template
Another area of confusion is that people get mixed up between templates and methodologies. When you ask people if they have a methodology, they say "Yes. We have some templates."
A typical evolution is for an organisation that has no common way of doing things to develop templates in order to get some consistency in how things are presented. In fact you are saying "Here is a checklist of things you need to consider". The next stage is to add some instructions in the template which explain what each section means. Alternatively they might create a template user guide. Finally they may develop a process or methodology which tells people how to get the information that ends up in the template.
There is often confusion between templates and process.
Just because you have templates, it doesn't mean people know how to gather the information that goes in the template. A template may have a heading called "Security". The actual process may be something like:
If only a template is available, the person filling in the template might know nothing of the activities above. The entry might read "Not applicable to this project". This is the difference between a template and a process or methodology.
What should a methodology cover?
The following topics should be covered in any methodology:
Using a Methodology
Any methodology is not the way all projects will operate. It is a best fit. There will be variations for very good reasons. That is not to say it is variable at the whim of each team. There needs to be some guidance provided as to what is the sensible pragmatic approach for each project.
Gartner research found that a methodology applied loosely could improve productivity by 30%. Applied rigidly it improved product by only 10%. It should be a help to the project, not a hindrance. If you want to have your organisation use a methodology, there needs to be some champion who people have access to for help.
Objections to Using a Methodology
The following are some objections I have encountered, and how to address each objection:
It stifles my creativity?
I have my own methodology
My methodology is better
The methodology is not applicable to my project
The methodology (or template) has too much information
There is too much paperwork
Implementing a Methodology
A methodology is not a series of templates. It is a process that needs to be adapted to suit each situation. There needs to be someone who teams can talk with - someone who will mentor the teams in the use of the methodology.
One of the most successful implementations of a methodology I have been involved in is a government department. They have a full time methodology coordinator who trains, works with teams, and builds their feedback into the methodology.
Feedback is also important. The methodology will not stand still. It will evolve and become more applicable to the organisation. As such, there needs to be a mechanism in place to cater for "learning from experience".
Take it step by step. A massive change to the way people work is not as likely to succeed as incremental change. If your goal is to have people produce a plan for every phase, start by having them produce some sort of standard plan for the whole project. If you decide to introduce three gates for approval of funds, introduce them one at a time. You will probably find after the first gate is in place, your experiences will indicate that you need to slightly change the process for the other two gates.
Availability is another issue. Asking people to read a 400 page manual will not work. Giving them some high level training, and presenting information in a format where they can find the bit that is relevant to what they are doing right now has more chance of success.
A well structured, web based presentation is a must. People need to be able to drill down in a few clicks to find out what is relevant to them at the moment. Training them on the layout of a methodology web site is likely to have more impact then training them on the detail of the methodology.
Finally, learn to walk before you run. Introduce simple steps into the methodology first, and leave the more complex until later. Understand you are trying to change the way people work and think. There is bound to be resistance. Turn the ship slowly or you will find yourself making little or no progress.