Project Management Methods

There are all kinds of projects, and methods used to manage and organize them. Experts analyze types of projects, how they are managed and try to discover and report the reasons why some projects fail while others succeed. In the previous section, I talked about management of teams and how to have a healthy team so I'll avoid that concern in this section. This section concentrates on best practices and methods for managing projects. Best practices and methods that are most effective on a given project vary depending on the characteristics of the project.

Project Characteristics

Below I have listed some major characteristics that will influence team performance on the project and therefore affect risk. In some cases, when the project in conceived, the technology to be used or tools to be used may not yet be determined. However some preliminary ideas in these areas should be available during the inception phase of the project for a rough estimate of risk.

Size - Large, medium, and small.
Complexity - Simple through complex.
Tool Familiarity - The team may be familiar or unfamiliar with the tools to be used on the project.
Technology experience - The team may be more or less experienced with the technologies to be used on the project. This can be called high technical risk.
Static and Known Project Requirements - How static the project requirements are influence the project greatly along with the risk the team and/or management may not understand the requirements. If the project requirements are likely to change or the risk of incorrect knowledge of requirements is high, then the project has high requirements risk. This will greatly effect the best project management and development method.
Size of the team and effective team communication - This can increase or decrease requirements risk.

Project Phases

Most projects in one form or another go through the following basic phases:

Inception - In a conventional project, the project would be conceived during the inception phase. Customers and potential users would be interviewed to determine what the project requirements or system requirements are. Requirements may even be prioritized (recommended). During this phase manpower requirements and required tools typically may be defined so a budget and schedule can be determined.
Elaboration - A prototype may be built especially if multiple items are to be made. If multiple items are made, at the end of the elaboration phase, the construction phase would be planned. If multiple items are not made, there may be no elaboration phase, or simply some kind of design may happen at this point.
Construction/Production - During this phase the main work is done. Items are made according to the prototype or code is written according to design specifications and/or requirements definition. Required manuals are produced.
Deployment - During this phase the system is delivered to the customer's site. The system is set up and begins running. The customer is trained in how to use the system.

This is a brief description of a conventional project cycle. There have been many variations to this theme with regard to order and methodologies, but the work is essentially the same. If the above steps are taken one right after the other it is known as a typical waterfall development process.

Project Corrections

As most experienced managers and workers are aware, sometimes projects get out of hand and fail. Sometimes they drag on and on with team members being unable to fully understand how to complete the work or what work should be done. Sometimes a lot of work gets done, but the project is over budget and behind schedule. Sometimes the work gets done, but the market changes or the project does not meet expectations. There are many events that can cause a project to fail, but it is normally either due to team performance, lack of communication of project goals or requirements to the team, or changed requirements.

Various project management or development methods allow for project corrections to be made at different points along the project's life cycle. Some methods allow for constant corrections while other methods allow for few corrections. Whether a greater frequency of corrections is worthwhile depends on the project characteristics and the risks involved. Projects that have high requirements risk should have more opportunity for project corrections.

Project Planning

The amount of project planning that should be done is dependent on the characteristics of the project. Larger projects and more complex projects should have more up front planning.

Project Prototyping

Projects that are complex should have a significant amount of project prototyping. This prototyping would normally be a throw away prototype which is used to test the technology and the ability of the team to use it. In this way the technological risk is mitigated without jeopardizing the project. This testing should be done early in the life of the project, normally during the inception phase, and possibly during the elaboration phase. This testing can be done by temporary subteams of one or two individuals.

System Integration

Regardless of the size or complexity of the project delaying integration of parts of the system being worked on by different workers increases project risk. Therefore system integration should be done as often as is reasonably possible. This is because as more work is done, there may be more required to correct any wrong assumptions or errors made earlier in the project. If there is a high degree of confidence in correct communication between members of the team, this risk may be considered to be decreased, but it would be unwise to be overconfident in this area.

System Testing

The comments about system integration are also true here. System testing should be planned or done before or during implementation. This is an important aspect regardless of the type of project.

Quality

I have not mentioned a word about quality and don't really consider it when picking a development method. This is because picking the right development method for the right project will determine the quality of the project to a large degree. There are also other methods to further assure quality such as testing of the system or product by a quality team. The quality team would be a separate team than the developement team and its sole purpose is to find defects in the system or to determine general product quality. This document will not delve deeply into quality assurance mechanisms since that is a subject that other books cover and volumes can be written about it.

Development Methods

Different management and project development methods allow for varying amounts and times of the following:

Project Planning - More needed for large complicated projects.
Project Corrections - More needed for high requirements risk.
Project Prototyping - More needed for projects with high technical risk.
System Integration - Increases quality and lowers risk, especially useful for complicated and large projects.
System Testing - Increases quality and lowers risk, especially useful for complicated and large projects.

Some management methods include:

Waterfall Development - Much project planning, little to no project corrections, flexible integration and testing. Works well for small and uncomplicated projects where requirements risk is very low.
Rational Unified Process - Much project planning, frequent corrections, flexible integration and testing with both encouraged. Works well for medium to large projects with any significant requirements risk.
Extreme Programming - Less project planning, constant corrections, integration, and testing. Works well for teams of two to ten members. Works well for small to mid size projects with high requirements risk.

Although the Rational Unified process and extreme programming apply to software development, their development and management methods can be successfully applied to other types of projects.

Management Guide Contents Page