The Project Management Software Blog

Why Project Management Software? Part 3

2010-02-05T10:52:00.000-08:00

We are looking at core reasons that project management software is evaluated and used by organizations, such as our last post on too many projects. How about managing the people that are working on project (i.e. resource management)?

Resource management is a broad term, but what it boils down to is the difficulty in managing all of the people that are working on all of these different projects. How do we know who is getting their work done? Who is not? Who needs help? How much time are they spending to get things done? Are they working on the right things?

This becomes especially important in times of economic hardship. Companies have been downsizing and trimming their work force. That makes it all the more important that the resources they do have are managed effectively and utilized properly.

Project management software is not the "end all". What I mean is that implementing project management software will not automatically solve your resource management issues. However, it can be a very effective tool when combined with the proper processes. Look at it this way. You have to use some tool to manage your resources, even if it is a piece of paper or a whiteboard. At some point, it becomes unmanageable without an effective tool. This becomes a big reason that people look towards project management software. It simply is too hard to piece all of the information together for good decision making and to take proper action.

A good project management software system should enable you to answer at least the following questions:

What are my resources working on?

What is the status of the work that my resources are working on?

Who is overloaded (has too much work assigned)?

Who is underutilized (does not have enough work assigned)?

Who is performing and who is under performing (who gets work done)?

Do I have enough resources to handle the upcoming projected workload?

Until next time...

Why Project Management Software? Part 2

2010-01-14T12:18:00.001-08:00

Let's take a look at "why project management software" in relation to the problem of having too many projects.

Many, many organizations utilize stand-alone tools for their project management software needs. These include spreadsheets, Microsoft Project, Outlook, white boards, post-it notes, email, you name it. I am a believer that tools need to be matched with good processes. Which means that you could use these tools along with good processes to do an effective job of managing projects.

However, I have also seen that when an organization gets to a certain number of projects, it becomes very difficult to use these stand-alone and single-project tools. Why?

First, it takes a long time to physically manage those. For example, it takes a while to open all of the Microsoft Project files to update their status individually. Or to open up all the spreadsheets. Or to open up the single spreadsheet (assuming no one else has it open) to update the status of a particular project.

Second, those tools are not designed for multi-project management (some are not even designed for project management). You can use Excel but it becomes difficult when you have to start managing multiple projects with multiple tasks in each of those projects, all from within a spreadsheet. Microsoft Project is built to manage individual projects (I know you can create master project files but I am still waiting to meet the person that loves how this works).

Third, the information in these tools tends to be dispersed around the organization. One person may have files about their projects. Another person may have different files about their projects. Getting and keeping all of this information together becomes very difficult.

Fourth, an organization wants to begin to answer certain questions that are difficult without a good project management software system in place. These questions may be things like what is falling through the cracks? Or what have we promised our customers next month? Or which resources are doing what? Or which tasks are late? Or which people are more productive? Or where have we spent our time - on which customers and projects? These and others are all questions that are very difficult to answer when you have to manage a larger number of projects and collect data points across those projects.

That is probably why we see a lot of people that start looking because they realize that there has to be a better, more efficient way to do things. And as fundamental as this is (having too many projects) it is a fundamental reason why organizations look at project management software as a solution.

Moving on...

Why Project Management Software?

2010-01-12T11:20:00.000-08:00

We have discussed implementing project management software, some of the benefits of it, and other related topics. I got to thinking, why use project management software? What are the fundamental, down and dirty, day to day issues that warrant making an investment with time, money, and resources in project management software?

Let's explore that. And I would love some help from you. What are some of the issues that you face now or have faced that may or may not be solved with project management software? Send those to me at blog@teaminteractions.com.

Let me define the term "project management software" for our purposes. With this term, I am referring to software that is specifically designed to manage projects. I am NOT referring to other tools (such as spreadsheets) that COULD be used to manage projects. The software could be simple, complex, in the middle (see categories), but fundamentally it was conceived to manage projects.

Why discuss this? Because sometimes it is hard to get past marketing hype, stated benefits, industry trends, etc. Implementing project management software takes a commitment. You don't just magically turn it on and all of a sudden achieve these fantastic benefits. It takes effort. It takes time. It takes resources. And usually it takes money. It's important to discuss why one would do this? What are the reasons? Are there real benefits that companies have experienced? Sure, but what are they?

In my next post I'll discuss the simple issue of having too many projects to manage.

Send your ideas to me at blog@teaminteractions.com and I'll add some of those to the list.

Tips on Scheduling, Part 2

2010-01-05T17:11:00.000-08:00

Last past we discussed organizational aspects of project management software scheduling. Now let's talk about a few technical aspects.

The most common form of scheduling I see is "spreadsheet scheduling", meaning that one could just as easily schedule in a spreadsheet. A manager will simply make a list of tasks and manually enter the start and finish dates for each of those tasks. No need for project management software here even though that is what is technically used. That is not to say that there is not a place for this. Some organizations may be small enough, their projects may be simple enough, and there may not be enough projects to go any further than this. For the rest (most) of us, let's talk.

What are the issues with this common form of scheduling? First, you are utilizing a labor-intensive process and not utilizing the strength of project management software. It takes a while to enter these dates individually, but even more time to change the dates when the project schedule needs to change two weeks down the road. Second, it becomes entirely subjective. There is no feedback from the software as to whether a schedule is even realistic or not. It is simply the user's best guess as to what the schedule is, or what they want it to be.

There can be tremendous value in using the scheduling features of project management software if they are used correctly. Now we can take that too far. In fact one of the common complaints about certain project management software packages is that they are too complex. But let me point out some basic concepts and functions that when employed correctly provide great value:

Dependencies
A dependency is simply a relationship between two tasks. The most common type of dependency is called a Finish-to-Start dependency, meaning that Task B will be scheduled to start after Task A finishes. Simply creating these dependencies between tasks does two things: it lets the software figure out all of the dates instead of the user thus saving time, and it provides a more realistic end date. There are more advanced dependency types such as Start-to-Start and Finish-to-Finish and using lead and lag times, but just getting that Finish-to-Start dependency can go a long ways.

Constraints
A constraint means that the schedule for a particular task is constrained. Most commonly, it cannot start before a certain date. Again, there are more advanced constraints out there, but utilizing a "Cannot Start Before" constraint provides the user with flexibility to manage exceptions to the "perfect" dependency world.

Effort Based Scheduling
Sometimes you need a true realistic picture of what the schedule will be. Effort based scheduling comes into play here. Effort refers to the amount of effort or work that a person will need to put in to complete a task. This is separate from the duration of a task, which is the amount of calendar time before the task is done. For example, Susan may need to spend 20 hours of her time to complete a task, while it may take her a whole week to get those 20 hours in and actually get the task done. If you can master effort based scheduling you can get a better handle on realistic schedules (durations tend to be wishes), and resource allocation (because you are being more specific for how much work your people need to do).

There are more features / tools that could be employed, but if you can master these three you will have taken your scheduling to a new level.

How does one go about learning and employing these tools? Use the help and training materials provided with the tools. Take a Microsoft Project training class. Even if you don't use this tool, it will help you understand the principles as many project management software systems are based on the same principles. Read a book. Go to a PMI chapter event and learn about training opportunities, such as with the new PMI scheduling credential. Check out the PMI College of Scheduling. Start using the tool yourself and figuring out how to use these functions.

If you become more proficient at these things, your scheduling will no longer be frustrating but more practical, insightful, quicker, and value-added.

Tips on Scheduling, Part 1

2009-12-18T08:54:00.000-08:00

Scheduling is often times at the heart of project management software. The project schedule drives so many other things such as task assignments, resource loading, reporting, status, etc., etc. Often times the fundamental processing of scheduling is difficult for organizations to adapt successfully. I see three primary reasons for this: 1) the wrong people are scheduling; 2) people are not adequately trained; and 3) there is not a clear process to follow.

Let me hit on these one at a time.

First, I have often seen organizations that want everyone to schedule projects. I have rarely seen this work effectively (not never, just rarely). Everyone has strengths and weaknesses. Some people "get it" in regards to scheduling. Others have a hard time just with the concept of scheduling. In addition, some people are analytical enough to create a good project schedule while others try to get by with the bare minimum or do not want to do it at all. Some people keep them up to date while others have no problem letting them stagnate or changing them too much (in other words they don't manage them). The bottom line? Unless you have a lot of people that understand project management and are analytical and disciplined, don't have everyone schedule your projects. There will be a wide disparity of project quality out there. Instead, select a few people that understand the principles and will manage them correctly.

Second, people cannot simply be thrown in front of a computer and start scheduling. Especially if they have not had a lot of project management software experience before. There are concepts in play to schedule effectively that must be understood regardless of what software is being used. These include dependencies and dependency types, constraints, predecessors and successors, and duration vs. effort (work). These must be understood. After that, they can be trained how to incorporate those ideas using the actual software.

Also, training is not a one time deal. Train them in the beginning, let them use the software, then hold another session to reinforce the principles and answer questions. Repeat this process. That will be far more effectively.

Third, make sure there is a clear process to follow. Don't simply turn people lose without a process. Even those with experience in project tools will schedule and do things differently. Do you want them to use a template? Do you want them to use dependencies? What do you want them to do when changes occur? Etc. Etc. Document the scheduling process and communicate that effectively so that everyone is on the same page. You want to be sure that scheduling is done in a way that will drive value and will cause you to achieve your objectives.

I am not saying that you can't effectively get people to schedule, it just takes the right kind of work and preparation like anything else of value.

In our next post, I'll offer tips more on the technical side of scheduling...

Tips on Reporting

2009-12-16T09:52:00.000-08:00

Reporting is a big part of project management software. After all, being able to obtain the right data at the right time to make the right decisions is one of the reasons to implement project management software in the first place. So let's talk a little bit about how to use reports more effectively.

First, it goes without saying that your project management software must have a reporting function in order for you to use it. Some software systems do, others do not. Some software systems provide canned reports that you cannot change while others (like EnterPlicity) provide a full reporting engine for you to modify and create your own reports. Some software systems have these reporting engines built into their interface, others use a third party tool such as Crystal Reports. Except for the lower end systems that are geared more towards collaboration, most systems should have some sort of reporting capability, or at least provide access for you to use a third party tool to create reports.

What's the point? You need to know what reporting capability is supported by your system, or what reporting capability is supported by the systems that you are considering. Often times the focus is on ease of use and features. While this is all well and good, don't forget the importance of reporting.

Second, what kind of reports should you be creating? I cannot answer that question dogmatically because that depends on your objectives. Are you trying to get a handle on resource utilization and usage? Then you are going to want specific resource reports such as the percent allocation of resources over your projects for a particular time frame; or the hours resources are assigned to each project; or which projects are taking up the most hours.

Are you trying to get a handle on your scheduling issues? Then you are going to want specific scheduling reports such as tasks that are late, projects that are in trouble, perhaps even earned value related reporting.

There are many other types of reports as well such as open issues, project risks, or requests. Some common reports that we find our clients get a lot of use out of include:
-A high-level red/yellow/green summary of all projects
-Tasks that are running behind
-Resource allocation over the next few months
-How much time resources have actually spent on which projects over the last few months (time sheets)

Identify a few reports (not too many) that are strategic and make sure they are getting run and disseminated on a regular basis.

Third, how can you disseminate reports? This is important to make sure that people can easily get their hands on the data. The simplest mechanism is that people can login and run the report. Another helpful mechanism is email. Some systems will allow you to automatically email out reports directly to a manager's inbox.

Fourth, you can use reports as a tool to further your implementation. You want to see good data in your report so that you can actually act on it. That is dependent on the fact that people are entering data and the data they are entering is accurate. You can use reporting to hold people accountable for entering in data appropriately. This can be especially useful during the initial implementation.

Identify those reports that are strategic and manage to them. Make sure that the data is there for you to make the right decisions. In the implementation phase, use these reports to show management the value that you could get out of the system if people are held accountable to enter it properly.

Reporting is a real value-add when done correctly. Be sure that you can get the reports out of your software that you need.

Tips on the Gantt Chart

2009-11-02T12:04:00.000-08:00

We cannot talk about tips on actual project management software usage without bringing up the Gantt Chart. The Gantt Chart is arguably the most popular (or at least the most commonly used) software tool. It became much more common with the release of Microsoft Project.

There are different schools of thought on the Gantt Chart. Some people use it religiously and it is a core part of their planning. Other people stay away from it religiously and never use it. Other people tolerate and use it because they believe that they must. How should you fit it in? Should you use a Gantt Chart and how?

Here are some tips that will help you answer that question.

#1: Understand the purpose of the Gantt Chart.

Here is an excerpt from www.wikipedia.org: A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e, precedence network) relationships between activities.

So the Gantt Chart is a tool to view the tasks (work breakdown structure), dependencies between those tasks, and the schedule of the tasks (and thus the project). The reason it is common-place is because these are items that most Project Managers want to see and it is an easy way to see them in one view.

#2: Understand the need for training.

A lot of people do not use Gantt Charts or do not like Gantt Charts. There are some valid reasons for this, but I have found that often the reason is a lack of training on how to use a Gantt Chart. We do not like nor do we use things that we do not understand. The Gantt Chart by its very definition includes more complex concepts such as task dependencies, parent vs. child tasks, constraints, etc. There is a minimum level of knowledge needed to effectively use these concepts to gain real value out of Gantt Charts. People that try to use Gantt Charts for more simplified purposes become frustrated.

What that means is get some training. Understand the concepts of dependencies, constraints, and parent / child tasks (or summary / detail) tasks. Then understand how to apply these concepts in a Gantt Chart.

#3: Understand your needs, objectives, and culture.

A lot will depend on your particular organization. If you need to create detailed schedules, then you really need to look at using Gantt Charts. If you do not need to manage schedules in any detail at all, or you have a culture that is very collaborative and not very detail oriented you could probably use a simple task list system instead.

If you are having problems with items being late, then using Gantt Charts could be a good tool to help plan better.

The bottom line is, match up with your organization's needs, objectives, and culture. How important is scheduling to you? If it is very important, then look at Gantt Charts.

Do you use Gantt Charts? How do you use them? What are some common problems that you experience with Gantt Charts? Send those to blog@teaminteractions.com.

Tips on Tasks Part 2

2009-10-26T14:50:00.000-07:00

In my last post, we discussed tasks and how to use them in project management software. In this post, let's finish that discussion with some guidance into how to use tasks in a project management software tool.

You can read the earlier post here.

First, you need to understand how you use tasks within your organization. If you are a collaborative organization without formal project schedules, then you can use a simple task tool without the need to break out into sub tasks or create more formal project schedules. If you do need more formal project schedules, such as in a product engineering environment, you will need a more sophisticated tool to break out tasks into sub tasks and schedule them.

In general, here are the most common tools to manage tasks in a project management software system:

1. Simple Task Manager. Some tools have a simple task manager tool where you simply create tasks in the project. You don't break them out into sub tasks or fit them into a project schedule, you simply create tasks. If you have more of a need and culture for collaboration without much formal project scheduling, this would be a good type of tool to investigate. This is more collaborative in nature where there is not a lot of control over the specific tasks within a project.

2. Gantt View. By far the most common type of tool is the Gantt View. The Gantt View enables the creation and breakdown of tasks along with the scheduling of tasks with dependencies and constraints for a complete project schedule. You should use this tool if you have a need for more formalized project schedules, and it is important to track the status of schedules / the impact of falling behind in any area of the schedule. By its nature, this will require a little more time to understand how to use it, but it will be well worth it in the long run.

3. Work breakdown structure. A work breakdown structure is simply a breakdown of the work that is required to complete a project. It typically breaks down tasks into sub tasks into more sub tasks until you get down to an appropriate level. A work breakdown structure tool could be a hierarchical tool showing this almost like an organization chart, or it could be an outline tool showing it in outline format. Most project management software tools show a work breakdown structure in an outline format (such as in a Gantt View). However, some tools have a specialized work breakdown tool for this very purpose. You should use this type of tool if many of your projects are different, you have to break out the work each time, and it is vital that you thoroughly break out the work before even thinking about scheduling (p.s. we built both methods into EnterPlicity to support the different needs).

How do you use tasks in your organization and what tools do you use? Send your comments to blog@teaminteractions.com.

Tips on Project Management Software Usage

2009-10-14T11:55:00.000-07:00

We have discussed a lot of different topics around project management software in this blog. They included topics such as the selection and implementation of PM software. But what are some tips to actually use project management software effectively? I thought it would be helpful to get down and dirty on some specific topics, such as what is the right way to use a Gantt View, types of reports that you should be creating, etc., etc.

Let's start with the topic of tasks. I will deal with this in two separate posts.

How should you use tasks in your project management software? Besides projects, tasks are a fundamental building block of most project management software systems, from stand-alone desktop tools to high-end PPM systems. A project is typically broken up into tasks and sub tasks: actionable items that someone is actually going to perform.

I should say that not everyone breaks a project up into tasks. Some organizations only want to track high-level project information. It depends on your needs and objectives. For example, a high-level PMO (project management office) or corporate office may want to track high-level project information, but leave the day-to-day task breakdown, scheduling, and the management of such to individual groups and project managers. In their case, they are not concerned with breaking projects out into tasks.

But for a majority of organizations, tasks are important. Why? Because projects are too high-level. The work needs to be broken down into pieces that can be assigned to individual people, and tracked to completion. Some common problems we see that organizations have are a lack of visibility into project schedules, a lack of visibility into what resources are working on, and a lack of visibility into what is actually done and what is falling "through the cracks".

How can you find out what the true status of a project is if you don't know the true status of the tasks (actions) that are being performed to complete the project? How can you know the true workload of a resource (person) if you don't know the number, load, and schedule of the various tasks (actions) that resource is being asked to do? Tasks are fundamental to solving these problems.

In light of that, it would be very beneficial for us to manage them correctly and with the appropriate tools that match the specific needs, objectives, and culture of our organization.

So how should you use tasks? How far should you break them down. What types of tools should you use?

I'll offer some simple guidelines in our next post...

No Discipline

2009-09-28T20:37:00.000-07:00

This is another topic on how to tackle common project management software implementation problems. Here is a golden one: what if there is a lack of project management or process discipline within your organization? In other words, things are very informal, they are not process-driven, things are very loose, and there is not much of any discipline to use project management processes much less a formal project management software tool?

This is a tough one. I think there are two sides to this coin. One side is that you have to get the process stuff down before implementing a tool. I agree with that in principle. If you don't have good processes, what good is a tool going to do? But there is another side of that worth considering. Sometimes, in reality, a tool can help be the driving force behind a move to instill more process and discipline in the organization. Let me float this out there. If you know your organization needs to improve, what is going to be more palatable to the organization? Instilling a lot of process and discipline, or implementing a software system? Process and discipline don't usually go over well, especially when there is no driver or accountability for them. But software can sometimes be more palatable. It's not quite as scary. But in implementing the software, you can use that as a driver to begin to instill some process.

That may sound a little far-fetched, but I have been thinking about those types of scenarios. Some organizations just aren't going to go out there and setup a lot of formalized processes and discipline. But they just may go for a project management software tool. If the tool is implemented in phases, with a focus on simple processes, and you take a baby step approach, before you know it you may just find yourself with a few more processes than you ever had before. The risk, of course, is that there will be zero adoption.

It is something to consider in my opinion. Ideally, you have processes setup and you implement a tool to support those processes with accountability. But sometimes in reality it doesn't work that way. So what should you if this is you, and you decide to do this? Take it slow. Don't try to accomplish too much. Set an easy attainable goal. Get people used to having the system around. Slowly add another easily attainable goal that is aligned with a process that needs to be implemented. Show lots of value. How does this make people's lives easier? Stay true to your culture. Be flexible and adjust as time goes on.

Agree or disagree? Email me at blog@teaminteractions.com.

The People Side

2009-09-22T09:04:00.000-07:00

One item that I would like to address is the people side of a project management software implementation. After all, it is the people who will make it successful or not - the people who are managing, using, training, implementing, and analyzing data from the software.

First, my apologies for the long delay in posts. Sometimes you have those crazy months and this last one was one of those. Last week I was at a conference and visiting clients. We were also a sponsor of the PMI chapters in Washington, DC and New York City (Manhattan). It was very interesting and a lot of fun. Thank you to those I personally met and talked with in those meetings. I hope that those of you in New York City had fun with our "Who Wants to Be a Millionaire" presentation of EnterPlicity.

Now on to the people side of things. I am not going to convey my own information to you as much as pass on something that I read on this topic. There was a blog entry posted by Donald Seers yesterday on eWeek on Project Managers and whether or not they are too focused on technology and tasks vs. people. Project management software can be a great value-added tool to help an organization gain competitive advantage. I would almost go so far as to say that organizations in certain industries / markets need to have a tool such as this to stay competitive. I believe that gone are the days where late schedules, poor resource management, inefficient project management, etc. are acceptable. Too many organizations (aka competitors) are at least working towards getting past these obstacles. Most of these organizations are utilizing project management software. The successful organizations are marrying project management software with the right processes and discipline.

Which brings us to our point. The software in and of itself is not enough. You cannot just throw software out there and expect it to be successful and be adopted. There is both a process and a people side to it. We have talked in this blog about the importance of setting objectives, planning, training, buy-in, etc. to a successful implementation. You should also factor in the people side. You have to build relationships with people. Fundamentally those one on one relationships are really going to help (or hurt) your implementation effort.

Read the article by Donald Seers here:
http://blogs.eweek.com/careers/content001/leadership/are_project_managers_too_focused_on_technology.html

Donald references an article on CIO:
http://www.cio.com/article/502263/Project_Management_How_IT_and_Business_Relationships_Shape_Success?page=1

What if Everyone is Too Busy?

2009-08-19T11:13:00.001-07:00

A common complaint when trying to successfully implement project management software is that people are too busy and do not have any time to learn a new system or a new process. Sometimes this is a smokescreen because people do not want to change (see Resistance to Change). But what if you truly are so busy that it is difficult to take even some of your people's time for this?

If that is the case, it is probably a symptom that you need better processes and tools to support both your current and future workloads. And it will never get easier to make that happen, it will only get harder.

So what are some strategies that you can employ?

First, don't bite off too much at one time. It is difficult for any organization to tackle a lot of change at one time. Ask an organization doing a multi-millionaire dollar enterprise system implementation about the cost, time, and impact to the organization. You usually do not need to do everything at once. Take it in phases. Where are you going to get the most value? Start there. Then incrementally add additional capabilities and processes.

Second, set clear, attainable, realistic goals. Make it crystal clear what people are expected to do. Don't make them spend time trying to figure it out. Document it. Communicate it. What are you trying to accomplish right now?

Third, train people on it. The trick here is not to overburden people with training that they don't need. Provide clear documentation on the process that you want them to complete in the system. Train them on this process. Don't train them on all the fancy features, but on what they need to do to complete their job. This will be different for different user profiles.

Fourth, build momentum. Achieve small victories in phases, and build on the momentum from that. Use the analysis from the initial data you collect. Bring a report to a management meeting demonstrating the value that can now be harnessed. Use the initial accomplishments, however small, to build momentum for the next phase.

Fifth, consider outsourcing. You may want to consider outsourcing the implementation to the vendor or a consultant. You have to be careful, because a vendor or consultant will naturally want to make it more complicated than it may need to be in the beginning. But if you can find a resource that understands your goals and objectives and wants to partner with you, that could take some of the burden off of you and the organization. They can design the training, produce the documentation, even conduct the training. In other words, they can do the dirty work - you can make the decisions. It's not right in every situation, but something to consider.

Of course, in spite of all of this, one of the key things is organizational support. If you don't have the right support, then quickly there will be a conflict between the project management software implementation and [insert competing priority here], and you will lose. So get that support at some level.

Have you implemented project management software? What has been your experience? Email blog@teaminteractions.com.

Resistance to Change

2009-08-10T21:53:00.000-07:00

How do you overcome resistance to change when implementing project management software? That is a common implementation hurdle to overcome. No matter how evident the problems may be, people naturally want to keep things the way they always have been. At least until the pain of doing it the old way is so great that they want to change.

I will not go into a detailed exposition on dealing with change because there are many resources that have been dedicated to that. I will simply offer up a few tips on how to deal with this issue when implementing project management software.

Communicate Often
We hear about communication all the time, but it is very important to communicate often, especially if you have a culture that is resistant to change. People tend to believe the grapevine, make things out to be worse than they really are, and fail to see real benefits. Good communication will help to alleviate some of this. A common mistake I see is that communication only happens when you need something from someone. For example, people are informed that they need to attend training without any forewarning or background communication. I believe that communicating early and often is a good thing. Let people know what's coming and what they can expect. How will it make their jobs better? What exactly is expected of them. Hold a brown bag lunch session and give people a preview of what is coming. Send out a weekly or monthly "newsletter". I'm sure you can come up with some good ways of getting the word out.

Use Phases
Sometimes we have a tendency to do too many things at once. People quickly get overwhelmed when too much is changing at one time, or too many things are thrown at them. Take it in phases. As much as possible, introduce new processes in phases. Keep things simple, and don't try to do more than you really need to do.

Understand Different Adopters
You will most likely have different types of adopters. Some people will be eager to get into the new technology and processes. Others will come if they need to, and still others will come "kicking and screaming." Find those people that are eager to adopt the new system and use those people as allies, educators, and evangelists.

Incorporate Enough Training (but not too much)
Training is important. It will help people be more comfortable with the new system. We recommend training people on processes along with the tool so that they are not just learning features of some system, but how to use this new technology tool to perform specific business processes. This will also help to prevent too much training (training people on features that they really don't need to do their jobs).

Accountability
This is not a popular word, but sometimes you simply need the management support to hold people accountable for the new processes. There is a saying that goes "what gets measured gets done". If people are not getting measured on adopting these processes, there will be a big tendency not to change and adopt them.

What can you add to the list? Comment or email them to blog@teaminteractions.com

50th Post

2009-08-05T14:37:00.000-07:00

This is just a post to celebrate our 50th post on The Project Management Software Blog. We have touched on topics such as project management software categories in the market today, strategies for successful implementations, how to select software, and more. Eventually, we will add categories to make it easier to navigate past posts.

We would love to hear your ideas for topics that you would like to see discussed regarding project management software. Send them to blog@teaminteractions.com.

Next post coming soon...

Another Implementation Problem

2009-07-29T12:29:00.001-07:00

Here is another common project management software implementation problem: no organizational support. I'm sure you have never experienced that one! How does this manifest itself? Sometimes openly, and sometimes more stealthily. Sometimes you are flat out told that the organization is not going to implement a project management software system in the first place. But other times, and I dare say more commonly, there are manifestations of this during the actual implementation. For example, people do not have time to work on the implementation or be trained; they are not interested in setting up the right processes; other priorities get in the way.

Organizational support and management buy-in is very important to be strategically successful with a project management software implementation (as with just about anything). What can you do in this case? I don't believe there is a simple black and white answer, but I do have some observations and suggestions:

Implement where you do have support
You may not have support across the entire organization, but you very well may have support within an individual group or department. Start there. Keep it simple. Setup the processes and implement the software within that area. Prove it out. Work out the kinks. Demonstrate the value. There is nothing like going to a meeting and being able to answer questions readily with data to back them up when no one else in the room can.

Set simple, attainable goals
You may be trying to be too aggressive and "shooting for the moon" with your implementation when you should start off with simple, attainable goals. In other words, you may need to walk before you run and think in terms of phases instead of doing everything at once. It will be easier (not guaranteed, but easier) to gain support when it doesn't seem like a daunting task to people.

Bide your time
It may simply not be the right time. The organization may not be ready or may have other high priorities that have to take precedence. Bide your time. Be ready. Have your information, pitch, value proposition, etc. ready to go. There will come a time when the organization is ready to listen. I am often amazed at how quickly this can happen. An organization just doesn't seem to want to move, and all of a sudden an event takes place that changes everything and this becomes a high priority. Usually this is some sort of emergency, such as a client threatening to cut ties because of yet another late delivery, or an executive lashing because there is no system or data to explain poor performance. Sometimes it is a new person that comes in at the right level with a mandate to improve productivity and processes. You never know. But be ready, at some point the time will come.

Implementation Problems

2009-07-24T13:13:00.001-07:00

I am going to switch gears a little bit to have a discussion about some common project management software implementation problems. All is well and good to pick the right tool with the right benefits and the right vendor who will partner with you, but that obviously does not ensure success. There are a number of roadblocks that can cause things to go south. These include lack of organizational support, resistance to change, competing priorities, etc.

One of those is a lack of technical expertise or availability of that expertise. In other words, to implement project management software in-house (except for stand-alone / simple solutions), it takes some technical expertise. Not everyone has that, or more commonly those resources are busy doing other things.

A simple method of addressing this is to adopt a Software as a Service (Saas) solution. These services are provided by many vendors as a way to circumvent any need for technical expertise. In this type of solution, the vendor hosts the software in their own environment / data center as a service to the customer. All the customer has to do is to log in to the site over the Internet. This is easy, convenient, and puts the burden on the vendor. This will probably cost you more in the long-haul as opposed to a direct purchase, but addresses the technical problem and is almost always cost-effective in the short term.

Here is an interesting blog I recently ran into, if you want to learn more about SaaS in general.

But what about those organizations (I'm talking about you, government) who cannot go this route because of security, regulations, or because they simply do not want to? In this case, you MUST have at least SOME internal resources to support the initiative (unless the vendor takes over complete responsibility for all of the technology, which would be very difficult). But there are a couple of things you can do. You can get the vendor more involved. A good vendor will be able to take care of many the technical aspects for you, even though it is in-house, and at least minimize the internal resources needed. This will cost you more, but it can be a good strategy. Just be careful, the vendor will not have the authority to handle everything, and you need to accept some responsibility in-house.

I would like to know what implementation hurdles you have, or have experienced in the past? Send them to blog@teaminteractions.com.

Final Considerations

2009-07-21T14:24:00.000-07:00

We are wrapping up a discussion series on selecting and evaluating project management software. Here are a few considerations before making your final decision.

At this point, you should have a good idea of which vendor you want to select. However, there are some remaining (but not unimportant) tasks to complete.

Ensure that you understand the complete cost of the implementation.

If you have not done so already (which you should have), obtain a written quotation of the costs involved. Review this with the vendor to be sure that you understand it. Ask questions such as "what happens if in two months we need your help", etc. Will the vendor be charging you for a lot of professional services time or is what you see up front what you get? Can you do the implementation yourself, or will you be paying the vendor to do it? What if you want to add more licenses or subscriptions down the road?

Talk to other customers as appropriate.

Talk to some of the vendor's other customers and see what their experience has been like. What type of support have they received? Did they pay more than they expected? What is the vendor like to work with?

Review the contract.

Be sure that you understand the contract (or order form) that you will sign. How will future upgrades be handled? Even if you will be doing the implementation yourself, how much will it cost to get the vendor's help if needed? Does the contract say what you believe to be the true cost?

Let me also say that you need to understand the type of software that you are procuring. If you are purchasing a $200 stand-alone desktop application, you are probably not going to get a written quotation and talk with customers, as you would with a $20,000 package. So use some common sense there.

Review your objectives again.

Go back to your comparison chart and objectives and be sure that your selection is going to help you meet those goals. It is difficult at this point to keep the emotion out of it, including the "I just want this process to be over with" emotion.

Plan the implementation.

Don't forget to plan the implementation. This is relevant to the current discussion because you want to be sure you are ready, know when you want to complete the implementation, and be sure the vendor is on board (if applicable) with your plans. Plus you don't want to lose momentum. You want to keep the ball rolling and move into executing your plan.

Don't forget to leave your comments or email blog@teaminteractions.com with your feedback on what has been successful for you.

What's Next Part 2

2009-07-13T16:35:00.000-07:00

We have just a couple of posts left before wrapping up our series on selecting and evaluating project management software.

After compiling and scoring the different vendors, as indicated in the last post (part 1), you want to decide on a final project management software tool or a couple of final tools. Either way, I recommend that you ask for a second demonstration. The purpose of this demonstration is to confirm your previous findings, identify areas that you missed in the first demonstration, and go a little deeper to make a final decision. If you still have two vendors in the running, this will help you make a final decision. If you have narrowed the list down to one, this will still help you confirm your decision. You will find things that you missed in the first go-around.

In addition, you should use this as an opportunity to start planning your implementation. How will you use and configure the software? How are you going to implement your processes within the software? What will you try to accomplish in the first phase? Second phase? This all helps to get started on the right foot and make sure you are making the right decision.

You can also use this as an opportunity to interact with the vendor about the project management software implementation. Ask questions about this. What does the implementation entail? Who will do it? What do they recommend as a best practice? This is another tool in your belt for a successful implementation.

Now there are just a couple of things to wrap up...

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