INTRODUCTION

If you use no methodology at all in your project management, if all you use is your native cunning and survival skills, then over time it's possible that you will find yourself doing some of the things that make for successful projects. (I say it's possible, because you may not. Many people “ especially in software “ go their whole project management lives and never cotton on to what worked and didn't work for them in the past. As a result they never know, when starting out on a project, whether or not it is likely to succeed. They live their lives in permanent suspense , agitation and worry. Sometimes things work out, sometimes they don't.)

If you go from this first situation to using a methodology you should probably see an improvement. Hopefully the methodology will force you to do some of the things that make for successful projects.

Ultimately, however, it's only by applying the Ten Steps that you will be doing all of the things that make projects successful. The Ten Steps are the "best" way to run a project. Thus, the Ten Steps can serve as a benchmark against which to compare other approaches.

I mention all of this as a way of explaining where methodologies fit into the scheme of things. Methodologies cause you to do some of the things that make projects successful. A good methodology may cause you to do a lot of them. No methodology that I'm aware of guarantees success. The Ten Steps do, solely because they were derived from observation of what makes other projects successful.

If you are already using a methodology, here would be a useful and interesting thing to do. Compare your methodology to the Ten Steps. Take each of your methodology's elements and see if that element has an analog in the Ten Steps. For example, your methodology may describe a way to do estimating. The Ten Steps also describe a way (it's in Chapter 2). If you do this for all of the elements of your methodology, then for each element, three possibilities arise:

• It's in both your methodology and the Ten Steps

• It's in your methodology but not in the Ten Steps

• It's in the Ten Steps but not in your methodology

It's in both your methodology and the Ten Steps

This is the ideal situation. This particular element is essential to the planning and execution of your projects.

It's in your methodology but not in the Ten Steps

I would argue that you don't need it. It's window dressing. Your projects can get by without it.

It's in the Ten Steps but not in your methodology

This is a gap in your methodology. In my experience, some of the things that usually crop up here, and they almost always do, are:

• The methodology does not stop you from committing to impossible missions

• The methodology doesn't require you to put contingency in the plan

• The methodology doesn't make clear how you should manage subcontractors or outsource vendors

You can see a full example of a comparison of the Ten Steps and a typical methodology in O'Connell (1999).