The Use of Project Templates

Templates are the building blocks for reusing similar forms or documents on different project phase tasks of a project. In developing any documentation or assessments for a project, the project manager should investigate using the following:

Standard company templates Downloaded templates from the Internet Templates developed from the beginning Requested templates from special interest groups

PROJECT CONFIGURATION MANAGEMENT

I have found, on numerous projects, that project managers neglect to manage properly the configuration of the project (1) documentation, (2) software version, or (3) specific baseline.

Most project documents used are either in a draft stage or have not been approved by the client. Project managers share the responsibility for strictly enforcing the rule that a configuration identification process be established on the project, in order to identify all project baseline documents. The emphasis here is that only approved baseline documents with associated version control shall be used on the project. Documents should be able to be tracked based on the different version used.

The risk that is run by using unapproved project documents relates directly to the fact that the project team utilizes those documents to develop specific deliverables. The team may only find out later that the client rejected the deliverables because the client did not agree to the documents in the first place or did not review them completely. The result can be slippages in schedule and cost for the project.

Lastly, the project manager needs to insist upon and develop a method for the effective distribution and controlled releases of documentation and source code to the project team individuals or groups. The project manager normally employs a configuration manager or administrator on the project team to ensure that these necessary formal configuration reviews are executed and carried out on a regular basis throughout the project life cycle. The team members performing the configuration reviews will be able to inform the project manager or project office of the number of change requests for the project, the number of problems, and how well configuration management is being applied on the project. The project manager should identify that projects typically need the following baselines:

Functional baseline Allocated baseline Design baseline Product baseline

What happens when the client decides to change a requirement after the team has started work on the project? Many projects simply accommodate those change requests into the project and the work continues, irrespective of the slippage or effects that could occur later on. The solution to this scenario is for the project manager to insist on establishing a change control process on the project for these change requests, and the full team should be made aware of how this change control process works.

The change control process must have a mechanism in place for approving, rejecting, or pending change requests. These change requests should be fully evaluated to determine their impact on the overall project before any decisions are made about the requested change. Let's assume that a change has been approved for a minor modification to the project, and it is approved without an assessment being performed. Later on, it is discovered that the training manuals and Computer Based Training (CBT) courseware were not addressed when the change was approved, and this could result in the delay of training.

Figure 3.6 reflects the flow of change requests that would occur during the project. It is important for the project manager to realize that all project change documentation is kept at the project level. Once all testing has been completed on the project, project managers obtain the necessary change documentation (change requests, etc.) from the project office environment. Table 3.7 shows the configuration items to be placed under control on a project.

Figure 3.6: Managing change on the project

Table 3.7: What project items to identify and pace under configuration control

Project-Specific Items

Software-Specific Items

Project management plan

Legacy data from the client

Software management plan

Process specifications

Functional specifications

Interface specifications

Implementation plan

Source code and scripts

Operational user manuals

Database descriptions and schemas

Change requests

Prototypes

Reports

Commercial off-the-shelf software

Minutes of meetings

LESSONS LEARNED FOR PROJECT CONCEPTS

Many projects go disastrously wrong when the project management method is abandoned in order to respond to senior management pressure to speed up the project. The following are some lessons learned:

The initial project definition document has no reference to the existing technology or project anymore.

The project plan does not take into account the risks of integration with existing systems.

Involvement of other parties was not previously identified as part of the project.

Interfaces to existing systems are being raised as an issue during the last stages of the project.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment