 |
|
 |
|
|
| Home | - | White Paper Index |
Project Management & Software Development Methodology |
First published June 04 |
Neville Turbit - Project Perfect |
Rating |
 |
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.
|
|
It is important to differentiate between a project management methodology and an applications development methodology or software development methodology. A project management methodology covers all the things a project manager needs to do regardless of whether the project is a software development, package selection, or relocation of his department. PMBOK (Project Management Book of Knowledge - the PMI bible) covers nine areas of project management. They are: |
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.
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.
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.
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.
The following topics should be covered in any methodology:
| Breakdown | How is the overall project broken down into smaller components such as phases |
| Overview | What is the purpose, objectives, deliverables and typical timeframes for each component |
| Activities | What are the main activities |
| Inputs and Outputs | What are the inputs or prerequisites for each activity? What are the outputs or deliverable of each activity |
| Instructions | How do you carry out each activity |
| Participants | Who should be involved in each activity |
| Supporting materials | Tools, checklists, templates and other material that can assist the activity |
| QA | How do you manage quality at either the phase or activity level |
| Timing | How to estimate the time for each activity |
| Governance | What authority is applicable? This may include approvals, gates to be passed, mandatory activities and sign-offs. |
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.
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
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.
Putting some templates in place is a nice first step, but it is not a methodology. Make sure you understand the difference between templates and process. Also understand the difference between a project management methodology and other methodologies. To a lot of people methodology is a dirty word. It means bureaucracy, paperwork and constriction. You need to overcome this by providing support and flexibility in how it is applied. I have yet to see a methodology succeed by just presenting people with a series of books and templates. |
 |
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.
|
To date, 540 people have rated this article. The average rating is 4.10 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed. |
|
|||||||||||||||||||||||||||||||||||
