These are small yet important projects that need to be managed to
completion. They are often encountered internally within a department or business unit. Without a project manager, these projects will surely fail, and the business operation will feel the effects. These projects often take one month or less to complete, and they do not need the formal
approaches and project documentation that other projects do.
Typically, these projects would not need a business case, strategic
alignment, Request for Proposal (RFP), or any contractual documentation;
however, the project manager is responsible for ensuring that the project is managed according to the standard company deliverable process, in order not to lose focus. Practical examples of such small projects are (1) a server migration (2) or minor changes to a critical business application.
For smaller, more fluid projects, where it is better for each team member to work across as many roles as possible, a project manager may want to assure each individual that he or she is empowered to fill whatever roles are necessary to keep the project moving. A simple project is one where the risk to the business is low: The following list presents some guidelines to identify these projects.
The solution is based on a standard implementation (usually an off- the-shelf package).
The system does not cross business functions (e.g., sales and production) and does not involve a major redesign of business processes.
There are no major changes required.
The number of contractors to manage is only one or two.
There will be no replacement of the hardware type or operating system.
There are no dependencies caused by links to other projects in an IS investment program.
The organization has the experience and capability to handle this type of project (i.e., it has been done before, by this team, in this
business).
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 sho uld 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 integratio n 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.