If you are following along with our posts, you realize that we are reviewing the process of selecting and evaluating project management software. We discussed things like Preparation, Finding Tools, and Evaluation Methods.



What's next? What happens after going through a software demonstration and trial of your top systems / vendors?

It is important that you are following a process so that you are not simply leaning towards a system because the salesperson is outgoing or the system looks neat. The idea is that the system will strategically help you accomplish business objectives. That is why we talked about preparation, identifying your objectives, creating a comparison chart, etc. Now is a good time to review that work. We all have a tendency to get bogged down with evaluating tools and forget the forest for the trees. Review your objectives and other preparation materials before making further decisions.

After you have done that, take a look at the project management software systems you have reviewed and your comparison chart. Hopefully you have documented things along the way and have notes on your comparison chart for the various tools. Your goal here is to make a decision on either a final tool or no more than two final tools. Several things may happen here. It may be inherently obvious which tool will best help you meet your objectives. You may realize that none of the tools really meet your objectives in which case you probably selected the wrong ones and you need to go back and review how you selected the "finalists". Most likely, more than one of the tools in your final grouping that you just got done evaluating will look good and could work.

In that case, if you have not done so already, you will want to score the different items in your criteria chart according to importance, and use somewhat of an analytical method of determining a total score for a tool. For example you may score each capability a score of 1 to 5 for each tool, and also weight each capability a 1-3 in terms of its importance to your organization. Then you can create some formulas to create a total scoring weighting the more important capabilities / features. If you do this, be sure that you don't just include features. Remember things like pricing, responsiveness, flexibility, etc. Those are just as important, if not more so, than pure features.

What do you do with this score? That will be part two...

I wanted to clear up a point about when to do project management software demonstrations and trials. It is not appropriate to do them for every software system that you may evaluate.

If you have not already done so, check out our posts on the project management software categories or download our Project Management Software Buyer's Guide. These will provide you with a snapshot of the available categories in the market today.

I reference these because they are relevant for when you should do software demonstrations and trials. Here are some general guidelines:

Simple / Stand Alone Tools: you will most likely not get a software demonstration with these tools, but most of them will have a free trial.

Collaborative Tools: these tools will most likely have a free trial, and some may also offer demonstrations.

Mid-Size Tools: these tools often times offer both software demonstrations and trials.

High-End and PPM Tools: these tools almost always offer software demonstrations, but not always software trials.

I hope that clears things up and give you an idea of what to expect. I can see those poor stand-alone vendors now getting requests to give live software demonstrations!

I mentioned in a previous post that I believe conducting a project management software demonstration with the vendor AND conducting your own trial of the software both have merit and value. The software demonstration is a learning experience for both you and the vendor. The software trial allows you to get your hands dirty and see how the software really operates.



What do I mean by a software trial? I mean getting your hands on a copy of the project management software to use for yourself. That may be downloading it and installing it on your computer. More likely it means signing up for a trial account and using it off of the vendor's server(s) / data center.

As with the software demonstration, the software trial is not going to give you a lot of value unless you plan for it. A lot of people sign up for a software trial, login to their trial account, and then just poke around the software without any real plan. What's the point?

Here are some tips on getting the most value out of project management software trials.

1. Try and re-create your process.

Use this opportunity to try for yourself how you would execute your process in the software. If your process is to create a project with certain key information collected, and then resources are somehow made aware of task assignments, try to do that in the software. You may not be able to do it exactly if for no other reason than time, but you should be able to get a feel for how you would do it.

2. Don't hesitate to contact the vendor for help.

A good vendor will be glad to help you, and show you how to setup your process in the software. But please, don't abuse it - there are other people the vendor is working with, so be professional and courteous of the vendor's time.

3. Don't forget about reporting.

You are going to collect a lot of data. Reporting is often times the most overlooked function because people are focused on inputting data and executing processes. Regardless of the tool you choose, you will have a wealth of information to report on. Run some reports that are going to help you achieve your objectives.

4. Explore other areas.

You may (will) not use all of the benefits of the software. But it doesn't hurt to try them out anyway. That may give you some ideas on what to do down the road and be a part of your long-term objectives.

5. Get others to try it.

Remember, you will not be the only person using the software unless you are evaluating a stand-alone tool. So get other people to try it as well. See how easy it is for them to navigate and use. However, be careful. Don't just give them a login to the software and ask them to see what they think. First, they probably won't do it because you are not asking anything specific. Second, they are not going to know what to do. Follow your process again. If part of your process is for people to login, see their tasks, and mark them as complete, ask them to do that. If part of your process is to upload documents, ask them to do that. Give them a list of tasks that you would like them to accomplish, and solicit feedback from that.

6. Document the results.

Document the results in your comparison chart or other documentation. Otherwise, over time you will forget which system you liked and the systems will start to merge together.

I wanted to pass on a couple of links to other articles that discuss software demonstrations. These reiterate some of the things we mentioned in our last article, but also offer their own insight.

The first is a short article by Capterra who puts together a comprehensive online software directory.

The second is an article by Gene Marks on businessweek.com.

How should you conduct a project management software demonstration? How can you obtain the most value from it and have it be a productive session instead of a useless dog and pony show?

In our last post, I suggested that you use BOTH a software demonstration and a trial (when possible) to evaluate software. They both have value. In this post, let's delve into software demonstrations.



General Observations

Software demonstrations should be a two way street. They should not be a session where the vendor simply shows all of the "cool things" the software can do. They also should not be a customer asking the vendor to show this and show that without the vendor being able to interject anything. This is an opportunity for the customer to learn from the vendor how they can achieve their objectives, for the vendor to learn from the customer in more detail what the objectives are, and for both parties to learn how the other party conducts itself and how to work with that party. It really can be a great opportunity.

Project management software demonstrations are often done remotely via an online web meeting. Gone are the days of a sales person (or team) coming on site to conduct a demonstration. That does happen, but unless it is a high-end item, it is rare. That is good and bad. It makes it easy to setup a demonstration and to quickly pass information. However, there is nothing quite like meeting face to face. Nevertheless, that is how things work today.

The Don'ts of Software Demonstrations
1. Do not ask for a software demonstration without communicating your needs and requirements to the vendor. What are they going to show you? The only thing they can show you is a dog and pony show which is of limited value to you. Software today can be varied and have a lot of options. If the vendor doesn't know what to show you, you may or may not see what you need to see.

2. Do not fail to invite the right people to the demo. If you are following a good process, make sure that the right people are in the demo so that they can also observe, learn, and ask questions. It may be appropriate to sometimes walk through an initial demonstration and then if it "passes" bring in a broader group. However, make sure that you are not asking for multiple demos just because you forgot to include someone.

3. Do not schedule a demonstration without the time to digest it. Don't have it scheduled up against two other meetings. You will lose a lot of the focus and value.

The Do's of Demonstrations
1. Communicate your requirements and objectives to the vendor. Tell them what you would like to see. Do this before the demo so that the vendor has a chance to digest it and plan for it. Some vendors will not do this, but some are very interested in helping you meet your objectives.

2. Better yet, communicate a process flow to the vendor. What do you see your process being? What is the process for starting a new project? How will progress be reported? Do not communicate how the tool will work - that's for the vendor to recommend. So you may need to be somewhat generic - but focus on the overall process you'd like to see.

3. Schedule enough time. Depending on the software, a demonstration could last from 30 minutes to a couple of hours. The project management software demonstrations we do typically last less than an hour, but you are still talking an hour or more when you start digging into deeper questions or more complex requirements. You should also have some time after the demo to summarize what you've learned and collect feedback from people. This should be done immediately after you get off of the phone.

4. Update your comparison chart with the information that you have gleaned from the demonstration. Include information on how easy the vendor was to work with, were they flexible, did they try and work with us or were they just trying to sell software?

5. Try to have demos from multiple vendors scheduled closely together. If you space them too far apart, they will start to blur together and you will forget key aspects unless you are very good at documentation.

6. Be prepared to have two demos for a single software tool. The first demo may be good, but the second demo should be great because both parties should understand the requirements and needs better. The second demo should be very close to the actual process you would use after implementing the software.

Follow those principles for a productive, value-added experience.

OK. You sent an information sheet to the vendors on your list and you have received responses. Now what?

Review the responses and set aside the tools that do not meet your most important criteria. Make a smaller list of the tools that do most of what you want. Note that it will be difficult to find a tool that does 100% of what you want AND is a good fit, but you should be able to find a tool that does most of what you need.



The question is what do we do now? There are various lines of thought on this. Some people think you should schedule a demonstration with the vendor, others think you should evaluate a trial site, others think you should go through a pilot.

I am a fan of going through a demonstration with the vendor AND setting up your own trial site for your own hands on evaluation. Why? Because there is value to be gained with both methods.

A demonstration reveals several things you may not learn otherwise:
1. It reveals functions of the software you didn't know were there.
2. It reveals new ways of accomplishing your objectives that you didn't think about.
3. It provides interaction with the vendor revealing more about how the vendor operates.
4. It reveals how important your business process is to the vendor. Do they give you a "canned" approach, or do they make an attempt at showing how to meet your particular objectives and process with their tool?

A trial site also reveals things:
1. It reveals how intuitive the software is to someone that has not had a lot of formal training.
2. It allows you to see first-hand how you can really setup your process in the system.
3. It allows you to get feedback from others in the organization.

My recommendation is to schedule a demonstration with each of the final vendors, and then evaluate your own trial site.

Let me go into some more detail on how to work through a demo...

You should now have a good list of potential vendors that will help you meet your strategic objectives. What do you do now? There are several approaches to that.

First, there is the "let's test all of the packages ourselves until we can't remember which packages are which and we get tired because there are too many packages to test and so we give up and just pick one" approach. A couple of problems here. You really do not have time to do all of the tools justice. You need to take more than a cursory look to really evaluate a tool. You run the real risk of hitting the "best fit" tool (the one that is a good fit for you) when you are tired and you don't give it much of a look. It takes time to learn how a system works and how it could accomplish your objectives. But hey, more power to you if you want to go this route.



Second, there is the "I don't want to test every system, so let's have the vendors show us their systems, so we will schedule a demo with all of the vendors, so that in 2 weeks we will never remember what we liked about which system, in fact we can't even remember what features went with what system now, so let's just pick the last one that we remember that looked all right" approach. I'm sure you can see some issues here as well, this isn't rocket science. You can't do a thorough examination, and it's not fair to the vendors to put them through an evaluation like this either.

Trials and demos have their place, but let's face it. You don't have the time, and can't do an evaluation properly that way. So what do you do with the list of vendors that you have?

Let me recommend an approach. Before you start conduct trials and demos of software, do one step first to save yourself a lot of time and mistakes. Let the vendors do the work for you, but in a fair way. Put together a list of questions derived from your comparison chart. Send this list of questions to each of the vendors on your list. Give them a deadline in which to respond.

This will do a few things. One, it will take what you think the vendor does and confirm it. Two, it will identify some vendors that should not be in the list. Three, it will tell you some things about the vendor such as how professional they are, how responsive they are, etc. You can tell these things from the way they answer the questions, how they interact with you, etc.

All you need to do is find a contact email address on the vendor's website. Believe me, they will respond to a good prospect looking for project management software.

This will help you identify the vendors at which you should REALLY take a closer look.

More on that...