The Project Management Software Blog

What's Next? Part 1

2009-06-30T11:30:00.001-07:00

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...

When should you do demos and trials?

2009-06-26T15:13:00.000-07:00

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!

Tips to get the most out of project management software trials

2009-06-24T16:56:00.000-07:00

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.

Software Demonstrations Part II

2009-06-18T12:03:00.000-07:00

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.

The Software Demonstration

2009-06-15T15:13:00.000-07:00

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.

Further Evaluating the Tools

2009-06-08T20:30:00.000-07:00

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...

Evaluating the Tools

2009-06-01T14:53:00.000-07:00

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...

How to Select Project Management Software: Directories

2009-05-29T14:57:00.000-07:00

In addition to Internet searches, networking, and news searches, here is another method to find tools: directories.

This is related to Internet searches, but still different enough to mention. There are several directories out there that list project management software tools. You do need to understand how these directories are populated, but they can be a good source of information. Here are a few that you may want to explore:

Web-Based Software Directory
http://www.project-management-software.org/
This online directory lists a number of project management software systems. The systems that are listed first are companies that pay to have their products listed. The rest of the listings are simply listings.

Wikipedia
http://en.wikipedia.org/wiki/List_of_project_management_software
Most people know of Wikipedia. The well-known online encyclopedia includes a list of "relevant" project management software systems added by users.

Capterra
http://www.capterra.com/project-management-software
Capterra is a great online software directory that contains listings for several different software types, including project management software. It includes companies that pay to be listed at the top as well as normal listings. Capterra offers an RFI service to request information from multiple vendors (but from what I hear, be prepared to hear from LOTS of vendors).

PMOpinions
www.pmopinions.com
PM Opinions is a fairly new site that contains project management software tools as well as a host of general project management resources.

There are many directories that I am excluding because of space, such as www.allpm.com or www.projectconnections.com. What you will find is that many of these directories will have many of the same tools. So you do not necessarily need to go through ALL of the directories, but pick a couple with which you are comfortable.

As we stated before, find tools, send them through your comparison criteria, and come up with a list of tools to explore further.

Speaking of which, we'll begin to talk about just that...how to explore further.

Send me your comments and your own experience to blog@teaminteractions.com.

How to Select Project Management Software - Finding Tools through Networking

2009-05-26T20:41:00.000-07:00

Here is another method of finding project management tools: through simple networking. In other words, ask colleagues and those you know at other organizations what tools they use. We talked about Internet searches, and news releases.

With networking, you still have to feed responses through your "filters" just like you would with other methods. After all, another organization may have completely different objectives and needs from your organization. Even if they had a great experience, if it isn't a good match, it won't be for you. However, it is yet another source of information to utilize, and with this method you can also glean additional information such as tips and how the company supports its product.

There are various methods of doing this if someone does not readily come to mind. Ask staff members what they have used in previous positions; ask people that you have worked with in the past; ask vendors and customers. Another good source is to visit your local PMI chapter and interact with other project managers.

Send these through your initial criteria, and add the ones that pass to your list of tools to evaluate further.

How to Select Project Management Software - Finding Tools through News Searches

2009-05-21T13:53:00.000-07:00

We previously discussed using internet searches as a method of finding project management software tools to evaluate.

Another often overlooked method is to search news releases. Why news releases? Because legitimate project management software vendors publish releases to let the world know about important news related to their company or tool. There can actually be a wealth of information in news releases. Not only can you find tools, but you can also glean information and get a picture of the tool itself. In today's world of social media, many organizations deliver information via news releases.

Let me give you an example. I went to Google News by navigating to Google and clicking on News at the top of the page. I entered "project management software" in the search box and returned 43 news releases in the past month, 121 for 2009. In the first two pages of results I found over 10 products, including one of which was focused on architecture, engineering, and construction. I also learned about a user conference, several product upgrades, available webcasts, and tips.

Is this the end all source of information on tools? No, but it is another tool in the arsenal to find and learn about project management software tools.

What I would do is the same thing you did for Internet searches - make a list of tools that pass your initial criteria and that are in your target category. Go to their websites to glean information. Take advantage of webcasts, etc. to learn more.

In a subsequent post, we'll cover a couple of other methods of finding tools, and then go into the next phase - how to more thoroughly evaluate the tools on your list.

Analytic Hierarchy Process

2009-05-18T14:40:00.000-07:00

I am jumping back just briefly to pass on a follow-up tidbit to our post on developing a comparison chart. You may want to take a step beyond that and come up with a more analytical process. One of our clients mentioned that they went through an Analytic Hierarchy Process to make their software selection. Essentially, that involves prioritizing or weighting the different criteria that you use to evaluate project management software. You use these priorities to assign numerical values to the different criteria. In other words, it becomes more analytical then emotional.

This helps you to determine which criteria are more important to you, and how two systems stack up against each other in terms of the more important criteria.

I am not going to delve into the ins and outs of how to do this. Others have already done that, so let me give you some links to some helpful resources if you want to take a more complex approach:

Wikipedia's Entry on Analytic Hierarchy Process

An Article by iSix Sigma Magazine

A "Miscellaneous" Tutorial by Kardi Teknomo, PhD.

How to Select Project Management Software: How to Find Tools to Evaluate - Part 1

2009-05-14T11:45:00.000-07:00

Ahhh, now we get to the fun part. At least, it seems like the fun part until you realize how many tools are actually available in the market. This is where your preparation will begin to come in handy.

One of the items that you are going to want to review is the software categories. You should already have a good idea which category (or categories) you want to focus on. Use this as somewhat of a litmus test to quickly discount tools that clearly do not fit. For example, if you are looking for a tool that can be used by your entire team or organization, then you can quickly discount stand-alone tools that have to be installed on your computer and are only designed for one user.

There are several methods of finding tools for which to do a more detailed evaluation. In this post, we'll talk about the most common: Internet searches. This means going to Google (or your favorite search engine), and searching for project management software. The most popular search term related to this is in fact "project management software". However, you could search for similar terms such as "project manager tools", etc.

Since you are reading this, there is probably not a big need to cover how to do this. Let me just emphasize that there are different types of information that you will find:

-Paid Search Results: most search engines have advertisements that will show up (such as the ads on the right of the screen when you search on Google). Understand that these are paid advertisements from vendors who pay to have their product listed there.

-Organic Search Results: these are the "normal" search results that are tabulated by Google (or whatever search engine you are using) and change over time.

-Directories: in both the paid and organic search results, you will find directories, which are lists of project management software. I'll give you some recommended ones in a subsequent post.

There is no magic to this - you will have to sift through the reams of information presented to you, using your preparation, to identify tools that may fit. I recommend making an initial list of tools that appear to fit in your category. I would also recommend a couple other "litmus tests" including a professional website, clients listed on the website, news releases from the vendor (i.e. there is something going on here that is worth talking about), and similar items. In other words, you probably don't want some freeware that some developer threw out on his website from his couch one weekend. You at least want the appearance of a company whose business it is to implement project management software.

But there are some other methods besides simple Internet searches. More on that soon...

How to Select Project Management Software: The Comparison Chart

2009-05-12T14:27:00.001-07:00

Right before we go out to find project management software tools, I recommend that you create a comparison chart. The purpose of the comparison chart is to highlight the requirements for which you are looking, and to be able to compare different software tools against those requirements.

I am using the term "comparison chart", you may also hear it referred to as an evaluation sheet, scorecard, or a number of different terms.

Let me make a quick side note here. I understand there are organizations that because of complexity or regulations need to go through a much more formalized Request for Proposal (RFP) process. That is not the focus of these posts, and there are plenty of papers, training courses, manuals, etc. on how to perform an RFP. Our focus is on the rest of us who want to follow a good process to select the right system, but do not have the time, money, or need to follow such a complex process.

Back to the comparison chart...on this chart you will list the broad features that you need. But I recommend including some other evaluation criteria as well. What are those, you ask? Here is a list of what I recommend:

Flexibility
Can the system adapt to how your organization does business?

Ease of Use
Will your people be able to use the system without an overabundance of training?

Category
Into which category of project management software does it fit, and does that category match with the needs of your organization?

Responsiveness
How responsive is the organization?

Pricing
Does the pricing of the system match the value you will receive?

Features
Does the system have enough features to meet your current and future objectives?

I'm sure there are a hundred different criteria you could include, but these will serve you well. If you want a more thorough discussion of these criteria, download our project management software guide.

Here is a snapshot of a comparison chart, also from that project management software guide:

You may even want to create a vendor-facing version of this document. Have them complete it and return it to you. In other words, have them do some of the work for you. A good vendor will do that. However, only send it to vendors at which you are legitimately looking. Don't waste a vendor's time. More on finding vendors in a subsequent post.

The Comparison Chart will help you to hone in on those vendors at which you want to take a closer look. Now, how do we find and evaluate those vendors?

Articles on Selecting Project Management Software

2009-05-06T13:11:00.000-07:00

I came across a couple of articles to give you someone else's perspective on the top of selecting project management software. I pass them on to you...

Project Management Features Article
This article is from a non-profit perspective, but talks about different types of features - a little different perspective from my most recent posting.

http://www.idealware.org/articles/fgt_project_management.php

CNNMoney.com Article
This article provides some insight into the thought processes of one organization as they selected project management software.

http://money.cnn.com/2009/04/03/smallbusiness/task_masters.fsb/index.htm?postversion=2009040610

How to Select Project Management Software: Determine Features

2009-05-05T15:18:00.000-07:00

Now we get to selecting the features that you need to have in a project management software system. This is where it gets a little tricky. Why? Because you don't want to be feature-oriented. You want to be objective-oriented. You want a system that has the features that will help you achieve your objectives. You do not want a system that simply has nice features.

That can make it difficult to simply make a list of features because there may be more than one way to accomplish your objectives. However, you want to have a general idea of the types of features that you need. For example, if one of your objectives is to improve your scheduling to get a much better handle on when things will be completed and prevent things from slipping through the cracks, then you know that you are going to need some level of in depth scheduling.

With that in mind, let me cover a very basic summary of some of the fundamental types of features that you will see out there in a project management software system. This should get you honed in on the types of features available, and what you may want to specifically look for.

Scheduling

Scheduling is a core component of many project management systems. Scheduling can refer to a simple list of tasks with start dates and finish dates. A more complete scheduling system will include the ability to add tasks, create subtasks, create a constraint, and creating dependencies between tasks (what tasks are dependent on the completion of other tasks). Dependencies may include finish-to-start, start-to-start, and finish-to-finish dependency types. Some advanced systems may include more dependency and constraint types but these are the most common. Often times, scheduling is done in a Gantt View (but not always). Higher-end systems may include advanced and complicated scheduling functions such as automatic leveling.

Resource Management

Resource management is a broad category of features that can mean many things. It refers to the ability to manage the resources that will be applied to complete projects. This can start at the low end with the simple ability of assigning resources to work (such as projects and tasks). This can move on to more advanced functionality, such as being able to view the utilization at which resources are working, keeping track of resource skill sets, viewing resource availability and workloads, and similar features. Some high-end tools will go further and provide features such as sophisticated resource leveling - automating the scheduling and assignment of resources.

Portfolio Management

Portfolio management refers to the management of projects as a portfolio of projects, instead of just individual projects. This thinking provides a much broader and more strategic view of the ongoing projects within an organization. Most low-end tools do not support this type of functionality. Mid-size and higher-end tools will provide features that range from organizing projects into portfolios, to reporting by portfolios, to tracking key information by portfolios, to portfolio roll ups, to (on the high-end) sophisticated portfolio ROI analysis.

Time Management

Time management refers to the tracking of time that people are spending on projects. This is often done in the context of a time sheet or time card. The idea is to find out where people are spending their time and how long they are spending on which projects and / or tasks. The purpose for doing this may be varied - to bill customers properly, increase productivity, identify overlaps, identify productivity problems, or many others.

Cost Tracking

Cost tracking refers to the tracking of the costs that are planned or incurred to complete a project. It can range from simple to very complex. It can include simply entering estimated and actual cost values for a task or project. It can mean tracking the cost of resources through calculations based on their hourly rates. It can mean ledgers or line items of expenses. On the high-end it can mean a complete project accounting system with invoicing and financial reporting.

Document Management

Document management is a common function used by organizations because documents are often times a key component of the management and execution of projects. This set of features can mean a place where documents can be stored together, to more sophisticated document management such as version control and check-in/out, to full-blown document management systems to manage thousands of documents, perhaps even a full-blown PDM system.

"Other Management"

I put this in a broad category because there are so many things that could fit into this grouping. There is a lot of data that can be tracked along with the core project schedules and tasks. This may include project issues, risks, ideas, requests, help desk tickets, etc., etc. There are a slew of these but in my mind they fall together as being "other" data to track along with your core project data.

Collaboration

Collaboration refers to features that help staff collaborate with each other. These would include things like emails notifications, blogs, notes, etc.

Reporting

Reporting often seems like an afterthought, but in reality is one of the most important features to consider. It sometimes seems like an afterthought because the initial focus is typically on getting data into the new project management software system. However, even the focus changes to getting data out. After all, that is usually the whole objective - getting data out for better decision making, analysis, to take action, etc. There are a range of reporting features from no reporting to some canned reports to full-blown custom report creation engines.

Back-End Features

Back-end features cover those that are geared towards interacting with the system programmatically, or on the back-end. For example, you may want to pull data from the system directly or integrate it with another software system that you already have operational (such as an ERP system).

Workflow Features

Workflow refers to the ability to automate the sequencing of operations, such as the approval of a project request, the notification of key individuals when certain events happen, or document routing. It is increasingly common, especially in higher-end systems.

Configuration Features

Some systems also have configuration features that allow you to configure your experience, such as by creating your own fields, forms, views, or similar items. This is sometimes overlooked as well, but is important if your organization needs flexibility to define the data that it will need to track to accomplish its objectives.

I am sure there are many more features that I am missing. However, these should get you started and give a feel for the things to watch out for. The key is not to look for all of these features, but to take your objectives and identify the category or types of features you believe you will need to accomplish those objectives.

As I alluded to earlier, have an open mind, as there may be more than one method of accomplishing your goals. A good vendor will want to understand your objectives and offer a recommended solution on how to achieve them.

Now that we have a better understanding of common features, we'll learn to roll this preparation work into a criteria worksheet and then begin to actually look for tools.

How to Select Project Management Software: Determine your Software Category

2009-05-01T22:37:00.000-07:00

One of the next steps in selecting project management software is to determine your target software category. There are literally hundreds of project management software packages in the market. If you simply start searching through them all, it can be very time consuming, not to mention confusing and overwhelming!

That is why it is very beneficial to know what you are looking for first. In addition to identifying some of the objectives, you want to hone in on the right software category. Some software solutions will be too low-end, some too high-end, etc.

I am not going to spend much time defining the categories because we have already done that for you. Let me link to some previous blog posts and to our Project Management Software Buyer's Guide, both of which define these for you:

Previous blog posts:
Project Management Software Categories: Introduction
Project Management Software Category #1: Simple / Stand Alone Tools
Project Management Software Category #2: Collaborative Tools
Project Management Software Category #3: Mid-Size Tools
Project Management Software Category #4: High-End Tools
Project Management Software Category #5: PPM Tools
Project Management Software Categories: Wrap-up

Click on the following link to download our Project Management Software Buyer's Guide:

http://www.teaminteractions.com/bg1.aspx

You will then want to prepare some criteria so that you can quickly judge the categories of the software packages at which you are looking. Here are some sample questions that you could ask:

Is the software web (or network) based (it is designed for multi-user access)? Or is it for one person running it on their desktop? -- This will determine whether it is stand-alone tool or not.

Does the software contain a full scheduling engine (typically in something like a Gantt View) that allows for tasks, subtasks, and dependencies at a minimum? -- If not, you may be looking at a collaborative tool instead of a full project management tool.

Is the software focused on core project management features (scheduling, task management, resource management, cost management, etc.) or collaborative features such as blogs, notes, etc. -- Again this is an indication of a collaborative vs. full project management tool.

What types of clients does the organization have? Are they large clients with thousands of users? Or are they smaller clients with tens (or may a few hundred) users. If they are thousands of users, you are probably looking at a high-end solution. If they are tens (or a couple hundred) users, you are probably looking at more of a mid-size solution.

Does the product focus on portfolio management features? If so, you may be looking at a higher-end PPM tool (or a high-end tool, period).

That is not an exhaustive list, but it should get you started.

How to Select Project Management Software: Preparation Part 3 - A Word About Buy-In

2009-04-27T16:39:00.000-07:00

An aspect of preparation not to be overlooked is buy-in. I am referring to getting key management personnel to "buy-in" to the project management software implementation. That means that they understand its value, recognize its strategic importance, support its implementation, and hopefully even help to set the strategic goals.

This is important for several reasons...

Project management software in and of itself does not solve anything. There are several strategies that rely strictly on the software that do not work. It must be married with strategic objectives, accountability, and proper planning. Management buy-in is important because by definition they should be determining what is and is not important. They will decide whether project management software and the implementation of it is important. If it is not important to them, then there will always be other projects that are higher priority that will detract from the implementation.

In addition, they provide the accountability. I know that people do not like that word, but if team members are not accountable for using the new system, it is not going to happen all by itself. Management needs to provide the accountability to be sure that people use the system and use it to further the organization's processes and goals.

Management also can go to bat for you. There will be a time where others in the organization will act as nay-sayers, have their own opinions about the implementation, or conveniently prefer that it goes away. There is where management buy-in comes in by re-emphasizing its strategic importance.

There are more reasons, but I think you get the idea.

The biggest question you probably have is how to you get buy-in? Good question. There is no black and white answer, but here are some thoughts from my own experience.

Sometimes you need to think smaller. It may not be possible or prudent to implement project management software for the entire organization. You just may not have that level of buy-in. But...you could start with an area of the organization for which you do have buy-in. This could be your own team, department, project, or group. Keep it simple, but follow the same principles (on a small scale) and demonstrate its value. When a manager can see the value, such as being able to access data real-time, that will help them to "see the light".

Sometimes you also just need to plant the right seeds and wait for the right time. The organization may not be ready right now, but you can plant the seeds by passing on the occasional article or tidbit of information. At some point (you will know when it is), the organization will suddenly be ready. I have seen this happen when an emergency occurs (such as when a key customer is ticked off because of a lack of project management), or when new management comes into place. You can be ready with ideas and suggestions on how to move forward. Have lunch with some people and gradually with tact, slowly make your case.

Comment on ideas you have had from your own experience on how to achieve buy-in.

How to Select Project Management Software: Preparation Part 2 - Solicit Feedback

2009-04-23T16:02:00.000-07:00

It is almost always a good idea to solicit feedback from others in the organization about their needs before starting down the road of selecting project management software. I'll explain why this is important, how to do it, and add some words of caution.

Why is it important? Three reasons. First, you will not be the only person using the system. Other people in the organization will be using the system as well. What do they need and even like? Two, you have your own objectives, but others in the organization may have a different outlook and may have objectives of their own that are equally important. Three, it will help your implementation. How? They will feel like they were consulted, and may even feel some ownership with the project. You will need their support during the implementation.

There are various methods of soliciting feedback, some formal and others more informal. Formal methods including asking them to formally submit requirements from their group, or conducting a meeting to collect feedback. I find informal methods, in general, to work the best. This is because it is the one-on-one interaction, the trust developed between you and other parties, that makes the biggest difference. Informal methods include going out to lunch with someone, chatting in the office, and asking their opinion informally. For example, I may go out to lunch with another manager and say "Hey, we're looking into selecting project management software to do x, y, and z. What would be some things that you would like to see that would benefit your group?" Or "what problems do you need solved?" This then becomes one of those situations where listening is better than talking.

The scope, size, and complexity of the project will determine how formal you need to get. A large organization will need to employ more formal feedback mechanisms, such as those that are a precursor to a formal RFP process, whereas a small or mid-size organization can be much more informal.

The types of feedback you need are problems that people are experiencing, what tools they are using now, and what they are trying to accomplish. Features are nice, but if you can solve a problem, so much the better. If you can solve a problem and help them accomplish a key objective, that is better still. It is good to understand what tools they are currently using as that will help you ascertain what type of system to employ: one that is more complicated, or one that is more middle-of-the-road.

I promised some words of caution. You need to solicit feedback from the right scope of people. Do not solicit feedback from everyone. Where are you going to implement this? Within your group? Across the department? Across the whole organization? Do not tread much outside of that target group of people. Otherwise you run the risk of diluting your requirements unnecessarily or causing your selection project to get much more complex than it has to because someone else wants to be involved in it. If you are not sure where you are going to implement it, ask yourself where you have buy-in from management. That is probably where you want to target, at least initially.

You also want to be careful what you do with the feedback you receive. You may have to run it through the "strategic objectives and true business value filter". People love to throw out features and wish lists, some which are good, some which have no real business value or necessity. But you will find key nuggets of information that can make a big difference in your selection and implementation.

Finally, you can solicit feedback ad nauseam, and never actually get to selecting anything. Don't take it too far. Get the feedback that you can in a reasonable time frame, then take action.

The bottom line, feedback almost always reveals things you did not consider, develops relationships, and helps your organization in the long-run.

How to Select a Project Management System: Preparation Part 1

2009-04-03T13:19:00.000-07:00

One of the questions we get from readers is how to select a project management software system. I mean, when you get right to it, what should that process look like? Where do you begin?

The first step that most people take is to bring up Google and begin an immediate search for project management software. That is all fine and good if you simply want to educate yourself and what is available in the marketplace. But you will quickly become overwhelmed, and you will not know what to look for if you do not first complete some initial tasks in preparation.

We recommend that you first determine your objectives, as you would any other project. What are you trying to accomplish? Why now? What does success look like? What strategic objectives is the organization trying to accomplish and how will this system fit into that?

This is important because if you do not have any measure of success, you won't be successful.

Here are some examples of possible objectives.

A product development company may be struggling with properly scheduling and maintaining customer commitments. Their objectives may be 1) create a central location where everyone can see current project schedules to reduce data collection time and misinformation; 2) make current project and resource assignment information readily available to make better, more informed promises to customers on new projects; 3) give salespeople information to know how their projects are progressing, and thus keep the customer informed; 4) develop an alert system to identify important items that are "falling through the cracks".

A professional services company (such as a company that does customer implementations) may have similar but also different objectives: 1) create a central location to show all active customer engagements; 2) create an issue management system to identify and track important issues with customer projects; 3) create an easy system to collect billable and non-billable hours worked by associates, thus reducing manually intensive operations; 4) automate the process of reporting for customer billing and informational purposes.

One of our government clients that utilizes EnterPlicity PM Software offers a unique and value-added service to other government agencies. But they had no hard data to back up what they really did (which made audits tough), and they needed to change to become more effective and even competitive (yes they have to compete). Their first objective was simply to find out where people were spending their time: which projects, deliverables, and deliverable types.

Other organizations may want to automate key processes in a workflow setting to be more productive, combine systems, stop things from falling through the cracks, centralize project management information to enable faster and more informed decision making, etc.

Document and prioritize these objectives. You will probably not be able to accomplish them all at once. You may need to go in phases. What is strategically more important and focus on that in the first phase. But have all of your objectives documented and in mind for future use during your evaluation.

This will be a working document meaning it will change over time as your business conditions and strategic situation changes.

Next: part 2...

Wrapping up Implementing Project Management Software

2009-04-02T14:55:00.000-07:00

Let's wrap up tips on implementing project management software.

There are lots of suggestions, best practices, tips, and advice on implementing project management software (or any software). We have mentioned some of them: accountability, communication, processes, going in phases, planning, seeding project management skills.

Here are some areas that we missed:

Buy-In: achieving buy-in on your implementation so that you have the proper organizational support. This doesn't have to be the top of the organization (though that would be the ideal), but it could be the top of the "sub-organization" in which you will implement pm software. This could be a department, group, team, location, etc.

Continous Training: I mentioned in a previous post to train people on what they need and not overwhelm them with all the irrelevant ins and outs of features and capabilities - focus on their key processes. Following that thinking, be sure that you provide continuous training opportunities, especially after they have had an opportunity to get their hands dirty using the system for a while. You could also gradually expand on the training content over time - again geared towards the function that you want a particular group to accomplish. In other words, don't expand just for the sake of expanding.

Work Closely with your Vendor: ideally, develop a close relationship with your project management software vendor. I recognize this is dependent on the type of software you obtain - a low-end / stand-alone system is probably not going to be conducive to this, but a mid-sized or high-end system certainly should be. A good vendor will want to support you, understand your needs, work towards making the system as effective as possible for you, and if nothing else listen for the purpose of continuous product improvement.

Leadership and Oversight: it is important for someone to be the point person for the implementation. It will simply not be as successful if you simply "hope" it will take hold. You need someone to manage it as a project (even if this is only a part of what they do), drive it, be a resource for people, and ensure it is meeting your objectives.

There are a lot more areas that we could spend a lot of time covering. Hopefully these are some helpful starting strategies and tips for you.

We are going to transition into various other topics, including some practical advice on how to go about selecting a specific tool.

As always, comment or send us a note at blog@teaminteractions.com.

Accountability

2009-03-02T11:41:00.000-08:00

This is another post in our series on implementing project management software.

If you missed the earlier posts, read them here:
Communication
All About Processes
Take It In Phases
Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

What about the a-word, accountability? No one seems to want to be accountable any more, and many people don't seem to want to hold people accountable. How does that apply to project management software?

Newton's First Law of Motion states that "Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it." OK, this isn't exactly scientific, but people in organizations will continue in their "state of motion" - doing things the way they have done them - unless some "force" is applied to change that.

This usually means that it is either too painful for an individual to continue operating the way they are operating (perhaps because they are tired of customers getting angry at them, or going through "fire drills", or something similar), or they are held accountable to perform a new process.

The whole purpose of implementing project management software is not to have some fancy new tool, but to strategically improve the organization in some way - to respond to customers better, keep things from slipping through the cracks, become more productive, etc., etc. That is only accomplished if people both use it properly and use it to perform your organization's key processes. This does not happen naturally, which means that the strategy of putting the software out there and "hoping" that people adopt it rarely works. Unfortunately, there must be accountability. And after all, that's a form of leadership, isn't it - setting the vision and expecting people to carry out that vision.

Accountability can be done in a number of ways - it can be something that is feared, or something that is rewarded. You know your organization and culture, and the purpose of this blog is not to get into the proper ways of motivating people.

The point is that project management software can be a strategic asset but there must be some accountability so that the organization is moving together in the right direction.

Send your thoughts and comments to blog@teaminteractions.com or post a comment!

Project Management Software Buyer's Guide

2009-02-24T16:34:00.001-08:00

Just a quick note to let our friends know that we recently released The Project Management Software Buyer's Guide. We find that a lot of organizations don't know where to start in selecting project management software. So we put together this guide that will hopefully be educational and point organizations in the right direction in terms of type of product, and the things to evaluate.

You can download it right from our website.

Send us your feedback after reading it by commenting here or emailing blog@teaminteractions.com

Communication

2009-02-16T17:01:00.000-08:00

We are going to discuss a couple of more methods of successfully implementing project management software.

If you missed the earlier posts, read them here:
All About Processes
Take It In Phases
Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

I want to talk about communication. Communication is a topic that has been discussed over and over again. In light of that fact, I do not want to discuss why communication is important. I am going to assume that you already realize that communication is important, and that communication while implementing project management software is no exception to that fact.

Instead I would like to focus on some practical tips to enhance your communication specifically when implementing project management software. Even more specifically, I will focus on the recipient groups and the type of information to convey to those recipient groups.

What I see happening quite often is that the majority of people in the organization either do not know what is coming, do not understand why project management software is being implemented, or do not realize what is expected of them. Often times, this is because information is not communicated properly. Now…let me take a side note here. One can say that you need to communicate in order to achieve buy-in from everyone. I don’t think that’s the goal because you will almost never achieve buy-in from everyone. Implementing project management software and the associated processes is strategic and while it is a good idea to solicit feedback, it is important to have demonstrated leadership that makes decisions on the implementation based on that feedback, and communicates those decisions and expectations.

Now, who are those recipient groups? In a nutshell, communication needs to be done upwards, downwards, and horizontally.

Upward means that you need to communicate to senior management what is happening, what is working, what support you need, etc. to ensure continued buy-in and to help some senior managers understand the strategic value of what you are doing. Hopefully, you have already secured a level of buy-in at that level, which means that you need to keep them in the loop.

How can you do this? Provide a weekly “progress report” whether it is asked for or not. If you have the opportunity, sit down one on one and provide communication while at the same time soliciting feedback. Make sure they know what is going on, what is being accomplished, and what problems have surfaced. You also need to listen to understand what is happening in the organization and how this project fits into and is affected by that.

Downward means that you need to communicate to all of your team members / user community / personnel / whatever you want to call them. Everyone that will touch the system needs to be included. This group often times gets missed. For example, a project management software system is selected, processes are put in place, a roll out schedule is created, and the average user walks into the office one day and is expected to attend training or start using this system. All they have known up until that point is from the rumors at the water fountain. While you don’t necessarily need their sign off, you do want to have them on board.

What can you do? Communicate to them periodically before they are expected to do anything. Let them know what is coming and when. Give them an idea of what will be expected of them. Try to identify the primary objections that will be raised and hit them head on. Hold a brown bag lunch session and at a high level give them a little “demonstration” of what their experience will look like and how they will be affected. Listen to their feedback. This will help to assuage concerns, make them feel like they are more a part of the process, will prevent them from feeling surprised, and may even result in feedback in areas that you simply had not thought about properly.

Horizontally usually means communicated with those “middle managers” that will need to support this initiative in order for it to be successful. Communicate with them early and often. Solicit feedback as to what their needs and problems are, and how the new processes / tools need to work in order to be practical in their areas. You will have to separate the wish lists and the grumbling from the true needs and issues to address. Try to find ways that will add value for them. For example, one of our clients was manually submitting time forms on a weekly basis and going through a rather lengthy paper routine to track and submit these forms. Well, since all of that information was now in the project management system, they soon saw the value in clicking on a report to do the same thing and eliminating a tedious process. Another client went through a reporting drill periodically to collect and concatenate key information about projects into a word processing document. They realized that by adding a few fields to the project management system, they could do the same thing with a lot less work, and thus eliminate another tedious process. Sure you are going to have the grumblers, but overall you will be in much better shape by communicating to this group.

How can you do this? Holding a formal meeting may not work too well here. You may want to try more informal methods. Sit down with individuals one on one in the office or over lunch. Let them know what you are doing. Send them information on the system, or perhaps even let them play around with a “test copy.” After this, you may want to provide more formal yet simple updates in an existing weekly staff meeting or similar mechanism.

You should also communicate to a fourth group: champions. There will be key people that simply “get” why this is happening and can become champions of the effort. They will champion it, answer questions, and deal with objections in their groups when you cannot be there. Stay close to these people, let them know they are important.

Finally, don’t forget that communication does not mean talking or providing information. Equally, if not more important, is to listen. Listen to the feedback that you receive. That point right there will improve your communication and relationships immensely. I have found that listening and not simply talking can diffuse tense situations, make people feel more a part of the process, and provide ideas that improve your implementation.

Those are some basic tips. Whatever you do, like any other project, be sure and communicate to all of these levels. It will greatly improve the opportunities for your implementation to be successful.

All About Processes

2008-12-15T15:19:00.000-08:00

The demand for project management software has not let up in spite of all the economic news of today. Hence the delay in getting some of these posts out. But we do have plans to crank these out much more frequently, so thanks for the patience!

This is another post in our series on Strategies for Successful Project Management Software Implementations. The following were previous posts in this series:

Take It In Phases
Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

Here's another strategy: focus on processes, not product features.

Project management software in and of itself does not solve anything. It is just a tool. Anyone can eventually learn how to mark a task as complete, enter time in a timesheet, or upload a document. But the point is not to use project management software, but to get real value out of it by being more competitive, more efficient, making better decisions, or whatever your objectives are.

By combining the software with the proper processes you achieve just that. When talking about implementing project management software, this is key. Here are some tips on how to accomplish this:

Document your Key Processes
What are the key processes that will support your primary objectives? Document these. What is the process to create a new project? To schedule a project? To update status? Running reports? For example, let's say that you are an engineering organization. Your process to create and schedule a project may be something like this:

Create the project and fill out the project name, engineer, product type, and sales person fields.

Use the template that corresponds to the product type.

Reset the project start date to the approved start date.

Designate which people will fill which roles.

That is simple but fulfills a potential objective: standardizing the project process for new products, and creating a central repository of key project information (i.e. the engineer, product type, etc.).

If you are a professional services organization, you would have a different process, and so on.

Train on Processes not Product Features
The tendency when implementing new project management software (or any software for that matter) is to train people on the use of the software. What features does the software have? How do you use those features?

The problem with that is that most of your users will not use all of those features, and the focus is on using the software instead of getting business value out of the software.

Instead, train people on how to implement the business processes within the software. That does a few things. It simplifies the process. People get trained on what they need to know instead on a lot of stuff that is unnecessary. It focuses everyone on the key objectives (instead of focusing on the software). And it produces results right away that are more inline with the primary objectives.

Do some people need to learn the software well? Sure. But I'll bet you anything that is a far smaller number of people than you think.

Use Templates Wherever Possible
Utilize project templates and other "template-like" capabilities wherever possible. This will help to instill your processes and provide some standardization so that information is valuable and not "messy". It helps to instill your processes because people are following templates and not making things up as they go along. It prevents them from doing things the way they feel like doing it.

There is a lot more that we could discuss about this, but I think you get the point. Focus on your processes and you will accomplish a lot more in a lot less time than if you focus solely on the software.

Take it in Phases

2008-12-01T14:14:00.000-08:00

This is another post in our series on Strategies for Successful Project Management Software Implementations. The following were previous posts in this series:

Planning: Another Key Strategy
Tackling Project Management Skills
Project Management Skills and Project Management Software
Implementing Project Management Software: Common Strategies

Another successful strategy that I have personally seen is to take your implementation in phases.

A common phenomenon in really any type of software implementation is "it's gotta do this-itis". People get very wrapped up in everything that the software MUST do for it to be beneficial. Never mind that they have absolutely nothing today and everything is done via pen, paper, and email. I suppose it is quite natural. After all, it truly can be an opportunity to expand the efficiency and competitiveness of an organization. But the key words there are "can be". Like anything else it must be managed correctly.

If you are familiar with project management, you have hard of the triple constraint on any project: time, cost, and scope. By adding all of these "must haves" to your project management software implementation, you are adding what? Scope, of course. Which means it will take more time and cost you more in terms of actual dollar cost or the cost of time. Not to mention the increased risk by adding complexity to the project.

So what to do? All of these "must haves" may in fact be beneficial. And there may be a minimum set of functionality that is required (although I would often argue that the threshold is lower than most people think).

The answer is phases. You have a short term and a long term plan. The key is that you don't try and do everything at once. That allows you to get a quick bang for the buck, get everyone comfortable, establish fundamental processes, and validate that your approach works in the first place.

For example, you may start off with a simple phase one whose objective is to get all active projects into the system, and train key personnel on how to create projects and associated schedules. That's it. After that, you may train others on how to update their status or, if you need to track time, how to add time spent on projects. After that, you may focus on making this truly a strategic repository by gradually adding complexity: documents, issues, risks, costs, etc. based on what your organization needs.

However you do it, the phased approach, wherever possible, works wonders. It provides some immediate benefit, enables the recognition of that benefit much quicker, and it simply isn't as scary to a user base that may be skittish about doing something new.

I'll be willing to bet that you will be surprised what you have accomplished in six months, as opposed to the organization that tries to do everything at once.

What has your experience been?