INFORMATION MANAGEMENT: STRATEGY, SYSTEMS, AND TECHNOLOGIES
M
ANAGING
P
ROJECT
M
ANAGEMENT
Nancy Blumenstalk Mingus
I N S I D E
Project Management Methodologies and Life Cycles; Selecting Project Management Methodologies; Implementing Project Management Methodologies; Implementing Project Management Software Packages
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 article discusses project management methodologies and life cy-cles, 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 man-agement 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 cy-cles relate to methodologies.
Project management methodolo-gies have been around for decades, but first started to become popular in IS in the early 1970s. These method-ologies usually have two compo-nents. The first is an overall process for doing things, while the second
P A Y O F F I D E A
Standards lead to organizations’ project man-agement success, whether simply for the infor-mation systems department, or for the corpora-tion as a whole. For the most effective projects, organizations should adopt such standards as project management methodologies, life cy-cles, and proper software tool support. Of par-ticular help are software packages for project management, process management, and time accounting.
consists of templates or forms required at specific portions of that pro-cess. While the process itself is the true methodology, most project man-agers 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 stan-dards 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 methodolo-gies. Such life cycles break a project’s life into a series of phases or stag-es. 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-imple-mentation 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 ver-sus vendor-supplied methodologies, as well as canned verver-sus custom-ized methodologies. It then describes the most popular vendor methodologies.
First, an exploration of the benefits and drawbacks of vendor method-ologies 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 head-aches involved in smoothing out process wrinkles.
On the downside, however, purchased methodologies require an or-ganization to change its existing practices to match those of the method-ology. 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 li-cense. In addition, some vendors charge thousands of dollars annually.
Some of the more popular methodologies for IS projects include LBMS from Platinum Technologies (recently acquired by Computer Associates) and Pride from Computacenter.
IMPLEMENTING PROJECT MANAGEMENT METHODOLOGIES
This section explains how to implement a project management method-ology. 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 de-partmental and client training regarding both the methodology and the standards.
Once an organization has either selected a vendor methodology or de-veloped one in-house, it is ready to start the long, often tedious process of creating project standards. While some of the purchased methodolo-gies 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.
After WBS standards are established, the organization 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 organizations 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 organizations use some type of automated time-keeping package to track time against projects. Time tracking has three project-related pur-poses. 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 man-aged 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 im-pact the project’s cost and schedule. To minimize this effect, change con-trol 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 depart-ment 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 organization can significantly reduce the number of changes to a project in its later stages by setting clear communication guidelines dur-ing planndur-ing, and then constantly updatdur-ing everyone involved in the project as it progresses, and doing so in a standard manner.
Methodology Training
While it is attractive to start training employees on the new methodology as soon as it is selected, this ‘jumping the gun’ can be hazardous to the ultimate success of methodology implementation. Certainly, the method-ology will evolve as employees start using it, but there should be a base of standards in place prior to training, lest employees, at a minimum, re-quire retraining. In some organizations, employees have actually revolted and chosen not to use the methodology at all — until standards have been established.
With at least tentative project tracking, estimating, change control, quality control, and project communication standards in place, the orga-nization is ready to conduct IS departmental and client training. This training can be performed in three ways: using outside consultants, who often develop the training as well; via internal employees; or using a combination of consultants and employees. If the organization chooses the combination approach, external consultants often develop the train-ing, whereupon they train the internal employees regarding how to de-liver the training.
Since both project managers and project participants must understand the new methodology, it often makes sense to have two separate classes.
The more in-depth class, for project managers and project leaders, ideally provides case studies, so they can actually practice the critical portions of the methodology. Although this type of training initially takes longer, the learning curve is less steep when project managers and leaders start fol-lowing the methodology on “real” projects.
The training for project participants can be less detailed, focusing on their roles in the new methodology. It need not specifically train them to use all the pieces of the methodology.
IMPLEMENTING PROJECT MANAGEMENT SOFTWARE PACKAGES
While selecting appropriate software packages is important, it is more critical to successfully implement these packages. This section discusses the differences between project management software, process manage-ment software, and time accounting software, and then examines various methods for implementing these packages. It also discusses the benefits and drawbacks of each approach, and outlines a process for successful implementation.
Although there are various software tools on the market today to help project managers manage their projects, having these tools does not a project manager make. Project managers must still perform the nine basic competencies of project management set forth by the Project Manage-ment Institute, an international project manageManage-ment professional associ-ation. Still, having these packages certainly can make performing these functions less arduous.
Package Types
Project management-related software tools are generally divided into the three categories of project management software, process management software, and time accounting software. Project management software packages perform scheduling, as well as limited project tracking. They do this by allowing project managers to enter project WBSs, assign inter-task dependencies, allocate resources, and assign effort/work estimates for each task. Once these basics are entered, the tool calculates and dis-plays the project schedule, often graphically, via either Gantt charts or PERT/CPM network charts.
After initial project schedules have been created, the tools allow project managers to baseline the original schedule, and track the project’s progress against that schedule. Since some of the project management tools are better at such tracking than others, organizations must weigh how important the tracking feature is to them when analyzing and select-ing a particular software package. Evaluation of this feature is particularly important because tracking is critical to future project planning.
Low-end project management packages include MS-Project 98 from Microsoft, SureTrak from Primavera, and Time Line from Time Line
Solu-tions. Low-end packages cost approximately $500, and have adequate scheduling features, but tend to have less robust tracking features.
Mid-range project management packages include Project Scheduler 7 from Scitor, CA-SuperProject from Computer Associates, and Project Workbench from Applied Business Technology (ABT). Mid-range pack-ages generally have better schedule-modeling features, better tracking, and better output capabilities, but the purchaser pays for it. They range in price from $500 to $1500.
High-end project management packages include Primavera Project Planner, usually called P3, and View from Artemis. The high-end packag-es include the featurpackag-es of the mid-range products, but also feature better multi-project handling capabilities.
Rather than focusing on project scheduling and tracking, process man-agement packages allow project managers to more easily plan their projects. Typical process management packages come with standard, yet customizable, templates for a wide variety of information systems projects. However, unlike the templates that come with some project management packages, these templates suggest dependency relationships between tasks, suggest the type of skills needed to perform each task, and generally also provide a variety of estimating techniques and metrics.
Process management packages include Platinum Process Continuum from Platinum Technologies (recently acquired by Computer Associates), which includes Process Engineer, formerly from LBMS, and Project Bridge Modeler from ABT.
The third type of project management-related software is time ac-counting software. These packages allow individuals and project manag-ers to charge actual hours back to project tasks. They do so by creating online and hardcopy time sheets, listing each team member’s tasks. The team member then keeps track of the hours spent on each task, and, usu-ally, the date that each task was started, as well as the date that each task was completed. This information is then transferred to whatever project management package in use at the organization. While time accounting software can be used without integration with project management pack-ages, when integrated, it can greatly simplify the sometimes difficult tracking functions in project management packages.
Two examples of time accounting packages are Team Workbench from ABT, and TimeSheet Professional from Timeslips.
Implementing Packages
Certainly, it helps project managers manage their projects more effec-tively if they break projects down into phases, activities, and tasks. Sim-ilarly, software package implementation tends to be more effective when phased in. Unfortunately, however, in their zeal to “get current,” organizations often try to implement too many changes at once. Thus
organizations that formerly had no tools at all might acquire three or more. The acceptance of those tools, and sometimes even the method-ology, plummets.
For organizations starting from scratch with project management-relat-ed software tools, the following order can help tremendously in imple-mentation:
• Time accounting packages. These packages should be introduced first because they affect the largest number of people. When using these packages, everyone on a project team has to track his or her time, and it is often quite a shock to people who have never had to track time before. When a time accounting system is implemented, it is critical that people understand that the purpose is not to police their work. Rather, the goal is to collect accurate data on how a cur-rent project is going, and to build an accurate database for estimating future projects.
• Project management packages. The organization will be ready to standardize on a project management software package three to six months after it introduces a time accounting package. Project manag-ers should be involved in the selection of this standard. Otherwise, implementing the tool will be more difficult because managers feel they were not included, or do not understand the rationale behind the selection of a specific tool. Having a core group of project man-agers supporting the selected tool enables the company to include them in pilot testing of the system, and in system training. This also forms a core advocacy group for the new tool.
• Process management packages. In another three to six months after the project management package is introduced, project managers will be ready to further hone their project management skills. With a few projects under their belts using the time accounting and project management tools, they will be able to more fully integrate the new process management tools into their project planning pro-cess. If, however, process management tools are introduced too soon, project managers might not have enough real project experi-ence to appreciate the benefits of the somewhat complicated pro-cess management tools.
CONCLUSION
Successful projects are critical to the success of not only project manag-ers, but to the whole IS department — and even to the company. Select-ing appropriate project management methodologies and life cycles, and supporting them with the proper software tools, can help immeasurably with project success.
Nancy Blumenstalk Mingus is President of Mingus Associates, Inc., a project management training and consulting firm headquartered in Buffalo, NY. She has been managing systems projects for nearly 20 years, and is currently implementing methodology training at a large systems integration company.
