A COMMON PERCEPTION exists that using the right project management software to help in managing a project virtually assures success. Nothing is further from the truth. Using a good project management tool will increase the likelihood of success but it offers no guarantee. In fact, history is replete with examples of projects that used high-powered software tools and still failed. About the best that project managers can hope for is having a tool that serves as an “enabler” for managing their projects—a far cry from an assurance of success. Software is just a tool. For example, a bad artist is still a bad artist despite using a good paintbrush. A poor marksman is a poor marksman even with the best rifle. A bad project manager is a bad project manager even while using a good project management software tool.
The performance record is quite clear, from information systems to business reengineering projects. Many projects have failed even after using the most expensive project management software available; others have succeeded even after using low-end scheduling packages. This record demonstrates that failing projects can have “good” software packages, while successful ones can have “poor” packages. What makes the difference is how project managers use the software to plan, organize, control, and lead their projects.
Ralph L. Kliem is president of Practical Creative Solutions Inc., a Redmond, Wash., consulting and training firm. He has authored/co-authored numerous books. He can be reached at [email protected].
Undoubtedly, the right project management software can generate great dividends for projects. It can handle large volumes of data, and it can perform routine activities such as calculating dates and generating reports. It can serve as a communications tool, especially if used as a data repository or connected to a network, and it allows experimentation with what-if scenarios.
To increase the likelihood of success when using project management software, it is imperative to focus on business requirements; identify technical features that satisfy those business requirements; give importance to interface capabilities; be objective in tool selection; capitalize on tool functionality; apply a total systems perspective; look beyond current needs; account for a learning curve; generate information, not data; and remember that software supports the project and not vice versa. The sidebar to this article shows things to consider when selecting software.
Focus on Business Requirements. While obvious, this point is often not the primary consideration when selecting project management software. Time and again, software is chosen for its technical capabilities and not whether it addresses business requirements. Some project managers purchase a highly sophisticated software package when a simple scheduling tool would suffice. Other project managers do the opposite and select packages that cannot handle the complexity or magnitude of their projects. The key is to know what business requirements to satisfy. Will the package be used for complex scheduling routines or for managing a simple project of a couple dozen or more activities? It's not uncommon to see project managers using Rolls Royce software when Honda Civic would suffice, or vice versa.
Identify Technical Features That Satisfy Business Requirements. This point is closely allied to the previous one. The capabilities of a package must address business requirements. If the package, for example, generates an arrow diagram when projects require a precedence diagram, then the business requirement is not met. Another example is a package failing to generate information in a desirable format. People may want graphics but the product only generates tabular information. Product functionality must be subordinate to the business need; otherwise, it is a technological toy for the user—but not a tool.
General Considerations for Selecting Software
Customization—The ability to modify standard views and reports. Example:Taking a template of a report and modifying it to suit specific needs.
Import/Export—The ability to use data generated by other packages, or to provide data to other packages in a compatible format. Example: Using data generated by another vendor's package.
Interface—How easy it is to navigate through the package. Example: Providing a graphical user interface.
Integration with third-party products—The compatibility of the package to work with other packages. Example: Using an “add-on” package to improve the interface of the project management software.
Network capability—The capability to support a local area network environment. Example: Banyan Vines or Ethernet.
Performance—The speed and reliability of the package. Example: Processing speed or amount of random access memory required.
Platform—The operating system supported. Example:Windows 95/98 or Unix.
Scalability—The ability to run on different types of machines. Example: Mid-range system or microcomputer.
Support—The services provided by the vendor. Example:Training or consulting.
Give Importance to Interface Capabilities. How many project managers purchase project management software packages that are little used, if at all? It's pretty common. Some project managers focus on functionality only to realize that the complexity of the package's interface leads to lack of use. Of course, the lack of use may be partially due to poor training or a latent fear of using a computer. More often than not the lack of use is because the interface is complex. The package may offer powerful capabilities but be unusable to many people. Interface is important if users are expected to maximize the capabilities of project management software. The preference in today's environment is to select tools that offer a graphical user interface and Web browser appearance. In addition, the package should offer a “wizard” capability that guides users in developing a project plan, and provide a tutorial that demonstrates how to exploit the software's capabilities.
Be Objective in Tool Selection. Many project managers purchase a project management package and then rationalize their decisions. They may prefer a tool from a specific vendor simply because of their experiences with other packages from that same vendor. They may also purchase a software package because they saw it advertised somewhere or they heard about it from someone else. These may be valid reasons, albeit subjective ones. An old marketing truism says that people buy on emotion and justify with fact. Often that is the case with software in general and project management packages in particular. What frequently happens is that the software was the wrong choice precisely because people did not make an objective selection. What they needed to do was develop a weighted requirements list and review several software packages to determine whether capabilities match requirements. The package that satisfies the most requirements should be the selected package. This approach reduces the tendency for impulse buying, which, for large projects, may result in a costly decision.
Capitalize on Tool Functionality. What this entails is not just knowing yourself but also knowing your package. If they conduct tool selection thoroughly and objectively, project managers should have a good idea of what the project management software can and cannot do. Too often project managers lose this knowledge and perform tasks in a manner that does not utilize the power of the tool they subsequently purchased. For example, some tools provide an e-mail capability linked to a specific task, yet few project managers and team members use that capability for various reasons (perhaps fear, lack of knowledge). Instead, they build a separate repository of e-mails that is distinct from the package. A lack of integrated activity between the project management software and the e-mail database exists, resulting in duplicate actions and time wasted on search activities.
Apply a Total Systems Perspective. A systems perspective is viewing a project as constituting different components interacting with each other to different degrees. These components can be functions, processes, people, organizations, tools, and so forth. Project management software is just one component, and it interacts with other components during the execution of a project. This point is often overlooked. Instead, the software is sometimes treated as the center of attention or as some ancillary part with no significance. In reality, it is simply a component that interacts with other components. Information is the “medium of exchange” between all components; project management software plays a role in handling and using that information. With that perspective in mind, it is easier to determine how well the software relates to and impacts other components. This perspective will reveal the value while executing the projects.
Look Beyond Current Needs. A project is not a static system, nor does it function in a static environment. Both are in constant flux. People transfer, requirements change, scope expands and contracts, production definition transforms, and many other things occur. It is important not to obtain project management software that constrains the project. For example, project managers find that they must integrate with other systems used by other projects but are unable to do so because of incompatibility with other packages. One package may need to be upgraded but no upgrade is available; instead, project managers must purchase another project management tool since the original one does not accept the database. It is important to select project management tools that offer flexibility and compatibility with a wide number of packages.
Account for the Learning Curve. Learning curve is the time and effort required for a person to become proficient in using the software. Everyone experiences a learning curve with new software. Project managers often overlook the learning curve; they put people right “into the fire,” expecting them to proficiently use the software immediately. The anticipation is that the tool is easy to use; the reality is that the software isn't easy to use because the people did not know how to maneuver through it. The result: Everyone is frustrated. People's confidence in the tool and in themselves deteriorates, and the tool is marginally used, if at all.
Interestingly, sometimes the tool is very easy to use, yet people still experience a long learning curve. The reason is that users may lack an understanding of basic project management fundamentals such as estimating, developing a work breakdown structure, constructing a network diagram, or identifying a critical path. This dearth of knowledge can cause frustration regardless of the easy interface of a package.
Generate Information, Not Data. It's common to visit projects and find that software is being used in a non-value-added way. A common mistake in using project management software is to generate numerous reports that create data, not information. Data has no meaning in itself, being just facts; information is data that is compiled and presented meaningfully. Project management software too frequently is used to generate data, not information. Many people receive reports that they cannot interpret or that are unnecessary. Ironically, too much data creates too much confusion. A significant power of project management software is its ability to generate the right information at the right time. If project managers fail to capitalize on that functionality, it can confuse and frustrate everyone. Once again, the tool is unused and the tool is blamed.
Remember That Software Supports the Project and Not Vice Versa. It's like the saying, “Don't let the tail wag the dog.” Too often, the entire project is centered around satisfying the tool rather than focusing on the goal of the project. Everyone works to satisfy the requirements of the software instead of the other way around. Many projects waste time putting data in a format that satisfies the needs of the software rather than working toward achieving the goals of a project. “Administrivia” becomes the focus, rather than the work, as people stop progress to satisfy the reporting tool. This defeats the purpose of the tool, which is to aid or facilitate project performance. If too much time is spent pacifying project management software, it may indicate a user problem or a not-very-user-friendly package.
PROJECT MANAGEMENT SOFTWARE: Is it friend or foe? Aid or anxiety? Every project manager wants it to be an aid. Unfortunately, few people know how to select the right package and use it cost effectively. Project management is replete with examples of project managers who viewed software as a silver bullet, which in the end did not help them to hit their target, but only to shoot themselves in the foot. ■
Reader Service Number 083
