9. A WILLINGNESS TO STAY THE COURSE
All IT projects face some level of difficulty, and much of it can be mitigated through sound management approaches. However, problems must be anticipated. As they arise, people will try to find ways to reduce the pain associated with the project. At this point, pressure will likely build to modify the project.
Some of the suggestions for doing so include:
§ A reduction in the features to be delivered. A phased approach to the project can be introduced, designed to shift parts of the project from the current schedule to some (often poorly defined) future date.
§ An approach that proposes that flaws or problems in the system be fixed by some workaround process. This process offers a solution to the current problem, but will often do less than what was specified in the original project plan. The idea is that the problem should be fully and correctly repaired, but there is no time to do that work now. The workaround is usually accompanied by a promise to return to the problem at some later date and make things right. When this occurs, the chance of correcting the problem at some later date will be close to zero.
§ A willingness to reduce testing standards and controls to meet project deadlines. Again, the stance is to wait to fix testing-related problems so that the schedule is met.
§ Abandonment of the project.
§ Obviously, if a project is in difficulty, some steps must be taken to correct the situation. These steps, and their ramifications on the entire project, should be carefully thought out and considered. It is important that everyone involved in the project realize that if there are project difficulties, there may be pressure to adjust the original plan. The plan should be flexible enough to allow adjustment, if needed. Organizations must avoid overreacting to problems and adapting the wrong approach to solving them.
Those responsible for the project’
s ultimate success within the IT department should
ensure the continuing support of the organization’
s senior management for the
project. If the project is of sufficient importance to be initiated, it should be adequately supported if things should go wrong. In obtaining senior management support, project managers must be willing to present an accurate picture of the potential difficulties inherent in the project. Insofar as is practical, senior management must be given a realistic assessment of the potential for difficulty and be willing to stay the course if things go wrong.
CONCLUSION
It is impossible to identify and manage all the potential difficulties and ramifications associated with IT development projects. The larger the project, the greater the probability of unforeseen difficulty. In large IT development projects, it can become a massive task to coordinate the various teams working on the project.
If organizations attempted to find and resolve all project difficulties and potential difficulties, it would keep projects from moving forward; this is sometimes referred to as “analysis paralysis.” This chapter does not strive for perfection. Rather, it tries to raise the awareness in IT installations and with the internal customer community, that the better prepared everyone is going into a given project, the greater the likelihood of a successful project.
While no one wants to be involved in an IT project that is less than successful, virtually every organization has project failures. If available, methods should be implemented to alleviate some of the difficulties and, as a result, improve the levels of IT service and customer satisfaction.
Of course, the nine factors outlined here create more work. However, this additional workload need not be a burden if the factors are understood and realized. When an organization incorporates the nine factors into the normal IT project development processes, the work required becomes less of a burden. If a relatively small amount of extra time and effort can improve IT projects and increase internal customer satisfaction, it is a small price to pay.
Chapter 3: Managing Project Management
Nancy Blumenstalk Mingus
OVERVIEW
As more organizations move to formal project work, it becomes critical to capably manage those projects. The best way to do so most effectively is to establish standards for project management that are corporatewide, or at least span the information systems (IS) department. These standards include project management methodologies and life cycles, as well as software packages for project management, process management, and time accounting.
This chapter discusses project management methodologies and life cycles, reviews some of the more common features of each, and explains the three types of software commonly used to support corporate project management systems.
PROJECT MANAGEMENT METHODOLOGIES AND LIFE
CYCLES
Although managers can manage projects without a formal methodology, having one can be a big help. This section explains what project management methodologies are and why they are important, and gives a brief history of project management methodologies. It also defines life cycles, describes some common IS life cycles, and explains how life cycles relate to methodologies.
Project management methodologies have been around for decades, but first started to become popular in IS in the early 1970s. These methodologies usually have two components. The first is an overall process for doing things, while the second consists of templates or forms required at specific portions of that process. While the process itself is the true methodology, most project managers consider the templates and forms to be part and parcel of the methodology. However, most project managers also agree that templates alone do not a methodology make.
Project management methodologies are important for two reasons. First, they standardize the way in which an organization manages its projects. This allows people from anywhere in the organization to talk with one another using the same terms and the same definitions for those terms. Presenting a consistent approach to project management via standards also allows project managers to cover for one another when the need arises. The second reason that methodologies are important is that they provide novice project managers with the tools to manage projects, without requiring a long learning curve.
Project life cycles generally go hand in hand with project methodologies. Such life cycles break a project’
s life into a series of phases or stages. The end of each phase provides a convenient project review point for senior management to institute go or no-go decisions, and also allows project managers to plan the next phases in more detail. While project life cycles can have many phases, the majority have three to five. They include some type of project start-up or initiation, a project construction or implementation stage, and, finally, a project evaluation or post-implementation review.
SELECTING PROJECT MANAGEMENT METHODOLOGIES
For organizations that do not have a methodology or are looking for a new one, this section explains what to look for in project management methodologies. It discusses the benefits and drawbacks of in house versus vendor-supplied methodologies, as well as canned versus customized methodologies. It then describes the most popular vendor methodologies.
First, an exploration of the benefits and drawbacks of vendor methodologies is in order. The greatest benefit of a vendor methodology is that the work is already done, which can save an organization 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 organization to change its existing practices to match those of the methodology. If it does not, then the organization must customize at least some of the methodology. These customizations can vary from minor tweaks of the process, to customizations so severe that the original purchased methodology is virtually obliterated.
Another drawback of purchased methodologies is their price. Many vendor-supplied methodologies cost $50,000 or more for a perpetual license. In addition, some vendors charge thousands of dollars annually.
Some of the more popular methodologies for IS projects include Dynamic Systems Development Method (DSDM) from Computer Associates and PRIDE from Computacenter.
IMPLEMENTING PROJECT MANAGEMENT
METHODOLOGIES
This section explains how to implement a project management methodology. It covers how to establish project work breakdown structures (WBSs), as well as estimating, tracking, change control, quality control, and communication standards.
It then explains how to conduct IS departmental and client training regarding both the methodology and the standards.
Once an organization 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, organizations will need to develop standards for those that do not have them.
Creating WBS, Estimating, and Tracking Standards
The first standard to be established is how project WBSs will be created. Many organizations develop project templates for the most common types of projects developed in the organization, 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. In turn, this speeds up planning, and allows better project tracking.