First, an exploration of the benefits and drawback of vendor methodologies is in order. The greatest benefit of a vendor methodology is that the work is already done, which can save an organisation literally years of developing an internal methodology. The vendor methodology has also been tested and proven to work, saving both the time and headaches involved in smoothing out process wrinkles. On the downside, however, purchased methodologies require an organisation to change its existing practices to match those of the methodology.

If it does not, then the organisation must customise at least some of the methodology. These customizations can vary from minor tweaks of the process, to customisations so severe that the original purchased methodology is virtually obliterated. Another drawback of purchased methodologies is their price. Some of the more popular methodologies for IS projects include Dynamic Systems Development Method (DSDM) from Computer Associates and PRIDE from Computacenter.

Implementation of project management methodologies

Once an organisation has either selected a vendor methodology or developed one in-house, it is ready to start the long, often tedious process of creating project standards. While some of the purchased methodologies come with standards for various project components, organisations will need to develop standards for those that do not have them. One of the first steps in implementing a project methodology is good planning. The only thing that really distinguishes projects from non-projects is the project life cycle. To develop a broad understanding of the generic discipline of the management of projects, both project managers and executives should address the broad range of issues affecting all stages of the life cycle in all kinds of projects [2]. This is certainly a tough challenge as it requires a substantial breadth of analysis and understanding. Maintaining a coherent conceptual view of the discipline at this broader level is generally difficult. We can, however, create a simple structure comprising project methodology; project team; tools and templates; business processes and development techniques in three separate levels to show this relationship (Fig. 4).

Creating WBS, Estimating, and Tracking Standards The first standard to be established is how project WBSs will be created. Many organisations develop project templates for the most common types of projects developed in the organisation, and then specify that project managers work from these templates. The advantage of this is that project managers are not “reinventing the wheel” on each project [2, 10]. In turn, this speeds up planning, and allows better project tracking. After WBS standards are established, the organisation must decide how estimates will be created. Estimates can be determined from expert opinions, weighted averages, statistics from previous projects, or from techniques such as function point analysis.

If organisations track their projects accurately and religiously, they can use statistics from previous projects to provide the most accurate estimates. This highlights the need for standards in tracking projects. Most organisations use some type of automated time, keeping package to track time against projects. Time tracking has three project-related purposes. The most critical is to accurately judge where a current project stands. However, other reasons that are almost as important are the uses of time tracking for project cost accounting, and for data collection, in order to better estimate the next project. To provide the best database for estimating future projects, these packages should allow tracking against each task in the WBS, reinforcing the desirability of standard WBSs.

Change Control, Quality Control, and Communications Standards

Standards for change control, quality control, and communications are equally important to project success. Change control in this context does not refer to changes in functioning production systems, but rather to changes in the project itself. The most common modifications to be managed are scope changes, generally expressed as a need for increased or different functionality. Because estimates are based on functionality as originally conceived, changes to initial functionality will obviously impact the project’s cost and schedule.

To minimise this effect, change control policies outline the project manager’s range of discretion for approving changes, and spell out escalation levels and procedures. While these two standards can be negotiated at the beginning of each project, general guidelines can prove helpful. Quality standards in an IS department tend to address how the department handles testing and production turnover. Some examples include how unit testing, system testing, and user acceptance testing will be performed. Communications standards are also important to successful projects.

The main reason that projects change as often as they do is that someone misunderstood a communication, be it the systems person or the client. The organisation can significantly reduce the number of changes to a project in its later stages by setting clear communication guidelines during planning, and then constantly updating everyone involved in the project as it progresses, and doing so in a standard manner.