I’ve always followed a traditional project management methodology, the Plan – Do. It fits my personality and it's how I’ve learned, but it rarely works well for clients or team members I work with and after years of trying to get other folks to follow this controlling project management style I have began to look for a better way. Agile methodologies may be that “better way”.

Let’s look at three basic types of project management. First there’s chaos and unfortunately this is how most firms I have worked with manage their projects. They jump right in and do things without proper planning, much control and little process. This is expensive and the main reason many web projects fail to be profitable and successful for the client. Secondly there’s Plan – Do. This is what most IT companies use. The idea is to plan everything out before development begins and hope to get it right and things don’t change too much. If things do, have a plan for making the changes then charge the client for the changes. Plan – Do is idealistic, resistant to change, not client friendly and difficult to manage. Thirdly there’s Agile which is an adaptive and flexible approach. Sounds good.

Agile differs in documentation, team participation and the project lifecycle. Jim Highsmith, of the Cutter Consortium and one of the founders of Agile, says planning and documentation should be barely sufficient. A lot of time is spent on planning and documentation. Perhaps this can be minimized.

Agile is based on short work cycles or iterations that deliver completed features all the while communicating with end users. When that set of features is accepted, on to the next iteration with the next set of features. The project is done in increments with approvals along the way. Plan – Do basically gets requirements in the beginning then builds the application and gets feedback at the end of a much longer cycle. Agile claims to eliminate a lot of the risk of acceptance because of the frequent end user feedback. Because of the feature based iterations, change is easier to incorporate into the project or at least change can be less expensive.

One key aspect of Agile is team participation. Team participation in planning and managing the details spreads the responsibility of the project across team members and gives them more ownership. That allows the project manager to focus on leading and communicating, the two areas he/she should be spending most of his/her time. Another example they suggest is allowing team members to choose what they would like to do rather than being assigned tasks and let people decide how they are going to handle those tasks rather than micro-managing development.

I recently became a certified Project Management Professional and learning that material seemed to solidify my conviction for the ol’ Plan – Do. The Project Management Institute’s guide to project management’s approach is very traditional, but can be adapted to Agile methodologies. The terminology is different, but the goals are the same: process and control. I have reservations about some things Agile advocates, but it all depends on the team and the project. The most import thing I will be exploring is to have a project management plan that fits the project and incorporates Agile methods where they might work better and get away from the mindset of only doing things one way and that is the PMI way.