The software selection project: tips from a pro
an interview with LG's Max Feierstein
At first glance, the Software Survey seems like “an embarrassment of riches”: enough choices to make you wish someone else would choose for you. Here's some guidance from an experienced project management implementation consultant.
When a company decides to implement project management, the software question can't be far behind. For most companies, selecting and implementing project management software is a major milestone in the process of transforming an organization from functional to project-based. And as the demand for project management tools grows, the market has responded with a bewildering variety of planning, scheduling, tracking and controlling tools. Matching a software product's functionality, price, and ease-of-use with an organization's needs, level of skills, and pock-etbook has become a project in itself.
As a companion piece to our annual Software Survey, PM Network reached out to one of our most knowledgeable members to give our readers the benefit of his experience. Max Feierstein, PMP, is a director with LGS Group, Inc., one of Canada's leading information technology consulting firms—and one of its largest, with 14 offices in Canada and France. As a project manager and consultant, Max has over 12 years of experience in designing and implementing project management systems and developing training programs in project management and systems design. Organizations such as the North American Life Assurance Company, the Canadian Wheat Board, the Manitoba Telephone System, and the Dept. of National Defence Air Command have had the benefit of Max's expertise. He is currently managing a project for the Credit Union Central of Manitoba to provide online banking services.
PM Network: Let's say I'm given the task of selecting a project management software tool for my company. Where should I start? What are the key features I should look for in a product?
Feierstein: Before looking at product functionality, first you need to do a user analysis. Basically, there are three categories of project management personnel: let's call them novice, intermediate and advanced. If you can determine which category the people who will be using the product fall into, you can slot your organization into one of these categories so that, for example, if the organization is at the novice level, you can immediately rule out the high-end “Cadillac” type of software.
The problem is that companies don't like to admit they don't know much about project management. People normally view their organization at a higher level of expertise than they really have. So they wind up with a product that is beyond their capabilities. Then, if roll-out doesn't go successfully, they blame the product.
PM Network: That's pretty common behavior, though. Can you suggest some strategies for avoiding that problem?
Feierstein: A third party, or outside, objective opinion can help; it can avoid some of the perils of self-assessment. A simple questionnaire that gauges project management knowledge can help. Questions like, “How many staff members have used the product, or a similar product, before? And “Do you have any PMI members on your staff?” reveal a lot. I've gone into organizations where they tell you, “Oh, yes, all our staff have been doing project management for years,” but when you ask, they never heard of PMI and some of them don't even know what a critical path is. So the first, most important, step is to determine the skill level of the people who will use the product.
Next, you'll want to do a needs analysis. This can be a very simple task, again based on a questionnaire, or it can be a two- or three-week project in its own right. You'll need to meet with the people who are going to use the product and find out, what are they going to do with it?
It's critical in today's IT marketplace to choose a vendor that is financially stable and has a good track record in the industry. Someone that will be there for you. Find out from other users what kind of support they offer; not only what is offered, but how good is it?
The way I view it, there are four things you can do with project management software, which I call PMOC: Plan, Manage, Organize and Control. Most organizations use this software primarily for planning. They never actually do any managing with it. Some questions that help determine where the organization is, in terms of sophistication, are: What sorts of reports will you need to generate? What kinds of things do you need to track? Will you be doing any earned-value analysis?
PM Network: And once you've identified the skill level and needs of the user, how do you evaluate the products that fit their user profile? There are so many choices now available.
Feierstein: I find that, in evaluating tools, price is much less important than a proper fit. It's a mistake to say, for example, “Okay, we're going to spend $500 on software” before you've done your user and needs analysis.
Then, you also need to do a vendor analysis. It's critical in today's IT marketplace to choose a vendor that is financially stable and has a good track record in the industry. Someone that will be there for you. Find out from other users what kind of support they offer; not only what is offered, but how good is it? And what sort of third-party support is out there for that product?
Then, as to functionality, we're back to the PMOC basics. How well does it do each one of these things? How good is the product at tracking, at capturing actuals? Other users are sometimes a better source of this information than the vendor.
Reporting is also a very important area. When it comes to figuring out if a product has the reporting capabilities you need, don't focus on what the vendor tells you it will do; focus on what you really need it to do. This sounds simple, but it requires a lot of thought and analysis. Reporting, both text and graphic, is so important. You have to look both at what “canned” reports are available and what kind of new reports the product will allow you to create.
Security is also an important consideration. Who has access to the plan? In some of the higher-end tools, you can control this very precisely.
And finally, consider the openness of the product; that is, how well does it integrate with the rest of your technical architecture? For example, does it work with a standard relational database? Microsoft Project or Timeline, for example, have their own proprietary databases while at the higher end, they run on standard databases, and are more easily integrated.
So, again, it's self-assessment. How will the product integrate with our environment? Does it fit the platform we are already using? Does it require people to become familiar with an entirely new platform, product, way of working?
PM Network: That brings me to the next question. Once a product has been selected, what are your recommendations for learning to use it effectively?
Feierstein: Number one, the tutorials that come with the product are generally very useful. Then, I find that PMI is an excellent resource; reading the articles in PM Network on the uses of various tools and the understanding of project management techniques…really, I've found that it's a very powerful way to educate yourself.
And of course, formal education, either vendor-supplied or by a third-party trainer. I usually find the latter to be a better value, both in price and in objectivity. A third-party trainer will tell you what you can't do with a product, which the vendor won't.
PM Network: What are some of the common pitfalls to watch out for in selecting PM software?
Feierstein: Focusing too much on price. One client I worked with, based on their needs analysis, really needed a high-end tool. But they had decided in advance that they would only spend a certain amount and no more. So they went with an intermediate-level product. A year later, they had purchased so many additional seats and add-ons, trying to keep up with user needs, that they'd spent more than they would have if they'd gone with the higher-end package in the beginning! It only initially looked cheaper.
Then, again, not accurately assessing the knowledge level of the staff. If they aren't knowledgeable about project management, no tool will help.
Senior management buy-in is critical. That's almost a catch phrase these days but, for example, if senior management isn't asking for project management reports, why would people do them, whether they have the functionality on their desks or not? The high-end tool becomes an overhead and not a benefit if senior management is not interested in project management.
Another pitfall is buying something that doesn't integrate fully with your architecture—there's not enough memory on workstation platforms to run it concurrently with other software, for example. If someone has to close out of everything and reboot every time they use the project management program, it's too much trouble, they're not going to use it.
Finally, the major thing is to remember that it's only a tool; it's NOT the solution. Frequently, organizations say, “okay, we're going to do project management—go out and buy software.” They ignore the importance of training. But, if I can use an analogy, if somebody doesn't know how to drive, it doesn't matter if they have a Chevette or a Lexus parked in the garage. You shouldn't complicate the process of change by giving novices high-end products, which, I'll admit, can be very hard to learn.
PM Network: Would you share with us some personal product recommendations for the various skill levels?
Feierstein: Well, in the novice category, I think Microsoft Project and Timeline are very good. They do an excellent job of planning and resource scheduling, although they are not as good at tracking and controlling. They work well for the person working on a single, stand alone project, which I estimate is about 50 percent of the project management community.
Then, at the intermediate level, I like Project Workbench from ABT. I've used it myself for about ten years. It has a combination of ease of use and power that really works for me. And with each new version, the usability keeps improving.
Among the Cadillacs, I'd have to recommend Artemis Views. It's excellent for corporate scheduling and organizing. It has an open, relational database. Though it's too powerful for beginners—even I had a hard time learning to use it—it's excellent for a large organization. You can manage all the projects in the company because it provides an “executive overview” of how things are going on multiple projects.
Also I'd advise people to look at how the products they're considering integrate with Lotus Notes. The newer project management tools are excellent in this respect. They incorporate standard project management tools, but also allow you to keep track of documentation through the Notes repository. Documentation and communication is so important in project management, and this gives you an extra tool to deal with these issues.
PM Network: Anything else you'd like to add?
Feierstein: Just that it's hard work selecting a tool. A lot of the issues I've raised here are infrastructure issues—they have to do more with the surroundings the product will be used in than with the product itself. Analyzing the infrastructure of the setting is much more challenging than merely buying a tool—but it makes the difference between success and failure.
Jeannette Cabanis, PM Network news editor, interviewed Feierstein by telephone at his office in Winnipeg, Manitoba.
PM Network • September 1996