TechRepublic columnist Tom Mochal receives dozens of e-mails each week from members with questions about project management problems. Mochal shares member questions-and the answers he provides-in a column each month. So often, IT pros tell TechRepublic that they receive the most insight when they learn about real-life situations that other IT pros are facing.
Question: How do I choose the right project management software?
I would be interested in obtaining guidelines for evaluating and selecting the appropriate project management software. The projects we are involved with span the planning to construction to maintenance phases. For our purposes, we would like it to relate well to Geographic Information Systems (GIS) data. This would allow for viewing according to geographical location or political boundaries.-H.C.
Answer: Use these six steps
I am frequently asked whether I have specific recommendations for project management software. In general, I don't make any software recommendations because I don't know the specific requirements of your situation.
Your question proves this point: In your situation, it would be helpful for the software to integrate well with GIS. That feature would not be a requirement for most companies, but it is important to you.
However, I can offer a process to help you select the project management software that is right for you. In fact, this process is not specific to project management software; it can be used in most any vendor or package selection process.
My description is based on a high-level process and will require you to drill down on the details to make sure the appropriate diligence is performed. For this approach, I am also assuming that you have already conducted a high-level, cost-benefit analysis and validated that your company does not already have another tool that will meet your needs. If you have not done this work, then you may need to start further back before you perform these steps.
- Plan the project. Plan a software acquisition project to ensure you have overall agreement on the objectives, deliverables, scope, time frame, approach, etc., for choosing the software. This should include the background on what type of tool you will be considering, why it is needed, where it will fit in your technology architecture, etc. You should also build the work plan that you will use to manage the project. This planning step takes place just as it would for any projects that you manage.
- Gather and rank business requirements. It's hard to select a tool or package if you are not sure what your requirements are. Again, this work is similar to the analysis you would do for any project. Ask questions such as the following:
—What will people be using the package for?
—What problem will the package solve?
—What features and functions are required?
Many times, you will not be able to determine all the requirements by just asking the customers. You can also look for other potential requirements by reviewing prior research from industry analysts, reading magazines and periodicals, and searching the Web. These searches can be used to generate potential requirements that can be validated by your customers. Each requirement should be weighted on a numeric scale, or high/medium/low, to reflect the relative importance of some requirements over others. (Other weighting scales can be utilized as well.). This total list of requirements and weightings needs to be reviewed and approved by your sponsor and major customers and stakeholders.
- Create package long list. At this point, look for any and all packages that might meet your needs. This can be accomplished by searching the Web, looking at trade magazines, talking to other companies, etc. The purpose of the step is to gather a comprehensive, but not exhaustive, list of vendors and packages that you want to consider further. If you think you already know the particular packages you are interested in, this step can be skipped-moving you directly to the short list. But this step helps ensure that there is not an obvious candidate that you are overlooking.
- Create package short list. Perform an initial, high-level evaluation of the long list, looking for obvious reasons to eliminate some of the alternatives. For example, certain products may not fit within your technology architecture, some may be too new, or some may be obviously too expensive. In some cases, there may be a feature that you absolutely need that is not available. The purpose of this step is create a short list of potential packages that look like they will have a reasonable chance to meet your needs. If the long list is not too large, you could send a Request for Proposal (RFP) to each candidate for feedback. You could also ask for product brochures and other literature. But, you must narrow down the packages to a small enough number that you can compare and contrast the remaining solutions during your final selection process.
- Evaluate package short list. This step can be the most difficult part of package selection. You must map the package features and functions against your requirements and weighting factors to determine which package most closely meets your needs. If you did not send out an RFP to the long list, you might want to send one out now to the short list. You can also interview the vendors, set up product demonstrations, and make vendor site visits. Usually, some type of numerical calculation is made based on how well the package meets each requirement, multiplied by the weighting factor. The package with the highest score across all requirements should be the one that best meets your needs. When you have completed this step, you should have a first and second choice for the package that best meets your needs.
- Make final selection and negotiate contract. In many organizations, the project team makes the final recommendation and then turns the process over to a formal purchasing or procurement organization. They are responsible for contract negotiation and legal details.
Do you have a project management question for Tom?
We can't guarantee that Tom will answer every letter, but he will read all of his mail and respond to the e-mails that will benefit the most TechRepublic members. Send us your questions, and we'll forward them to Tom.
I have described an overall process that can be used to make a package or vendor selection. Of course, if the software is complex and expensive, these high-level processes might be broken down into 100 distinct activities. In fact, for large, strategic purchases, such as with the Department of Defense, the selection process could take months or years. On the other hand, for more simple, commonly used packages, the process might be streamlined and completed in a matter of days or weeks.
Still, you must understand your requirements first and then go through a process of finding and subsequently narrowing down the field of potential packages and vendors until you can make an intelligent decision on which one to purchase. Then, you have the additional challenges of implementation, but that will have to be addressed in another column.
Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He's also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep.