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

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

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.

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.

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

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.

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.