© 2008 Team Interactions, Inc.
 
 
     
Thursday, January 14, 2010
Why Project Management Software? Part 2

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

 
 
Tuesday, January 12, 2010
Why Project Management Software?

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.

 
 
Tuesday, January 5, 2010
Tips on Scheduling, Part 2

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.