EnterPlicity Project Management Software & Resources

In a previous post, I mentioned that I had attended the 2008 PMI Mile High Project Management Symposium in Denver, Colorado. We were there as a vendor, exhibiting our project management software, EnterPlicity, and services. The keynotes were James Lovell, the captain of the ill-fated Apollo 13 mission and Gene Kranz, the flight director. I sat in on their talk and despite already knowing the story, I found it interesting to listen to their personal tale of events. I also thought about some facets of their story that illustrate principles that underscore the value of project management software in general and the importance of other factors in making it successful.


Let me start with a quick recap of the story. Apollo 13 was the third flight intended to land men on the moon. On its journey to the moon, an explosion in an oxygen tank crippled the vehicle resulting in a crisis that fortunately resulted in the safe return of the three astronauts on board. For a little more of a synopsis, I found this post on TechJunction:


http://eequalsmcsquare.com/technews/2007/04/13/back-in-time-april-1970-apollo-13-tells-houston-weve-got-a-problem/


Here are some thoughts.

First, Mr. Kranz and Mr. Lovell emphasized the importance of key attributes such as leadership, perseverance, hard work, respect, and teamwork. They could have focused on the benefits of the technology, or the reliability of the spacecraft systems, or on some other technical aspect which was clearly important. They did not. They attributed the success of the Apollo 13 return to the attributes of the teams that worked hard to bring the astronauts back. Often times the emphasis with project management software is on the features, technology, or bells & whistles that the software can perform. There is almost a mentality that good software will help us get better at project management. As with the spacecraft systems on Apollo 13, the technical aspects are important, but they are not enough. We must have leadership, discipline, teamwork, and similar attributes to truly gain the value out of project management software. You marry the right principles and processes with the right technology and you create a significant competitive advantage.


Second, the talk made apparent the fact that the unexpected will occur. It clearly did on Apollo 13. And it clearly does in our projects. Implementing project management software is another project. How you utilize it down the road will be different than how you envision it initially. You may have a different organizational plan, different processes, or you may decide to make it more complex or simple. That is why it is important that software be flexible enough to adapt. And that people are as well.


Third, we cannot discredit the technology itself. The entire Apollo program was built on technology, and in fact would not have been possible without the modern technology of the day. Project management software has some good technology to bring to the table. It is now possible to centralize (fairly easily) all of the information associated with our projects. That should not be overlooked. While the process side of things are equally important, the technology itself can drive important changes. In fact, sometimes it is easier to drive software than to drive a lot of process improvement. Ideally, an organization will work out its processes and then implement the tools to support them. However, sometimes it is realistic to get people on board with using technology, and then use that technology to drive the processes. It's a little backwards but sometimes in the real world it works. The point is that while technology itself will not solve anything, good technology can be a driving force for positive change and accomplishing new goals.

Fourth, training is important. The Apollo 13 astronauts and controllers simply would not have had a successful outcome if they were not well trained. People must be trained properly on project management software for an organization to utilize it effectively. Put another way,

the proper amount of the right training is important to gain value from the
technology

. There are two key phrases there. "The proper amount" means that people need enough but not too much training. Today, there are tools available that simply do not require days and days of training. It should be much simpler than that. However, there is a "proper amount" that is needed. "The right training" means to train people on what they need to perform their key processes. Everyone does not need to know the ins and outs of the technology. Some people do. Most people just need the right training to perform their processes. They also need the "conceptual" training to understand why they are doing what they are doing. They need to understand why we break out work and not simply how to move boxes around. Once they get all of that, they become effective users of the technology as well as effective project contributors.

I hope these "off the top of my head" thoughts inspire some thinking on your part. I'll pass more along as I think about them. We'll resume are postings shortly on the various project management software categories out there.

This post was delayed due to a busy week again last week. I was on the road in Denver, Colorado for the PMI Mile High Chapter's annual project management symposium. James Lovell, the captain of the ill-fated Apollo 13 flight and Gene Kranz, the flight director were the keynote speakers. It was an interesting, well-attended event. I will give you more information on that in a future post, including my thoughts on how their experience relates to project management software.

For now, this is the second in a series of posts on project management software categories in today's market. Click the following link to proceed to the first in this series of posts:

Project Management Software Categories: Introduction

Let's get on to the first software category: Simple / Stand-Alone Tools.

This category, in my experience, is the most prevalent category in terms of usage. Most organizations either use tools in this category exclusively or use tools in this category in conjunction with other tools. The most common tools in this category are spreadsheets and Microsoft Project.

Common characteristics of this category include working with one project at a time. In other words, a person has to open up one project, then open up another project, etc. to view each project's data. Another characteristic is that only one person typically has access to a particular project at any given point in time. Two people generally cannot open up the same project and make changes at the same time. Yet another characteristic is that information is often dispersed throughout the organization. It is rarely centralized in this category. That means that files for one project are stored with one individual, files for another project are stored with a different individual, etc. Unless an organization is really on top of things, this information is all over the place. Finally, tools in this category tend to be overly simple or highly specialized. In other words, they are very simple tools without a lot of sophistication or they are specialized towards a specific function, such as scheduling or estimating. However, they are still in this category because information is not centralized.

Let's reiterate a point made in the introduction to this series of posts. Is this category bad? No. Just different. It makes sense for some organizations to utilize tools in this category, whereas it makes sense for other organizations to utilize tools in other categories. You have to do the analysis for your own organization as to whether this category fits your organization and its current status (we'll cover that a little more shortly).

Along those lines, what are the benefits of this category? First, these tools are generally simple to use and understand. This is dependent on the tool, of course. Some people will never find Microsoft Project simple to use and understand, but if you talk about spreadsheets or other tools in this category they will. Second, people are often familiar with these tools. People are used to using spreadsheets, or Microsoft Outlook, or similar tools. Third, there is a low training curve. Because of the first two benefits, the training is much lower to implement tools in this category. Fourth, it is fairly easy to change processes because there is not a lot of rigidity in the tools themselves.

Along with benefits, there are always drawbacks. The first drawback is that information is spread out with different people and different files. Trying to do any kind of consolidated analysis is often very difficult and time consuming. In many cases it may not even be possible. Second, it is difficult to maintain. Because it is so easy to store different types of data in different types of files in different locations with different formats / layouts, it is very difficult to have any type of standardization or to maintain it in a cohesive manner. Not impossible, just very difficult. The third drawback is that it is difficult to do any type of roll-up reporting. What is Susan working on this month? That is a difficult question to answer when the information is located in 20 different files.

When should you consider this category? There is no black and white rule for any of these...you need to determine yourself what makes sense for your organization. A general "gray" rule, however, is that this is a reasonable category is you have no more than 10-20 active projects and less than 10 people working on those projects. That type of environment will help to minimize the drawbacks listed above. Of course, you may want to look at one of the other categories to obtain some of the benefits, but you can make this category work. On the other hand, if you have more projects or people than that, you quickly get into a scenario where it is very difficult to keep track of the project information with simple / stand-alone tools.

Next we will discuss the second category...

In previous posts, I covered the typical problem scenarios in which organizations find themselves in terms of project management software. In case you missed it, read part 1 now. I want to start now in the direction of talking about what to do if you find yourself in one of those scenarios. First, we'll discuss the various project management software categories out there. Then we'll discuss topics such as how to properly implement project management software, how to get buy-in, and other related topics.

It is not at all uncommon for me to be attending a conference or some event where I am meeting and talking with people in the project management community. It almost never fails that I receive questions that demonstrate a lack of understanding of the options available in the project management software market. This is not at all surprising. There are literally hundreds, if not thousands, of available software tools geared towards project management. Many organizations know that they need some help in this area, but they do not know where to start.

I am going to attempt to clarify that picture by identifying the main project management software categories. This will not be a list of project management software packages, but of the categories out there. For each category, we will discuss its characteristics, advantages, disadvantages, and even a couple of examples. We will also discuss what types of organizations should consider that category for their project management software.

A point should be made here. Is a particular category bad or wrong? No, of course not. Each category is different and will fit different organizations. It depends on your organization, its needs, culture, goals, issues, and objectives. Can I tell you which category or which software tool is best for your organization? No, not without a lot of analysis and learning on my part. However, I can and will give you some guidelines so that you can determine which category (or categories) may be appropriate for your organization. After all, you know your organization much better than I do. Can anyone say that a particular project management software tool is "the best"? No. It again depends on an organization's needs and how a particular tool fits into those needs.

With all of that in mind, next time, we will start with the first category which is...you'll have to wait until next time!

OK, it's time for part 3 of where organizations struggle when it comes to project management software. I do not mean to oversimplify the scenarios in which organizations find themselves, but these are generalized scenarios that I have found.

In Part 1, I commented on organizations that have virtually no project management tools. Part 2 covered organizations that rely on simple or stand-alone tools, such as Microsoft Project, spreadsheets, email, etc. The third scenario is the organization that has a tool or set of tools in place but finds that the tools are too complex to achieve any kind of significant value from them.

Am I saying that higher-end, complicated tools are bad? No, just different, and they need to be utilized in the right scenario to meet the right needs with the right organization. For example, if you have a large organization of thousands of users and you need to centralize project management software into a single, comprehensive system...you need a high-end complicated tool. However, most organizations do not need this level of complexity, and it can in fact be detrimental.

How do you know if your software is too complex? That's not quite so easy. The simple answer is to evaluate usage. If people in the organization are not using the software, that may be a sign it is too complicated. However, that can really be oversimplifying the situation because there may very well be other root causes. For example, people may not have received enough training, or they have received too much training (you heard that right...more information than what is needed for them to do their job), or there may be a culture that does not have the discipline to use a more formalized tool.

Another factor to evaluate is how much time are you spending administering and doing mundane tasks in the system. If a lot of time is spent on administrative maintenance, that may be a sign that the system is more complicated than what you need.

Yet another factor is the flexibility available in the system. These systems can be very "customizable", but often require consultants or integrators spending a good deal of time to make it so.

What can you do if you have an overly complicated system? After all, it is difficult to move in another direction after making a significant investment of time and money. However, there are some tips and practices you can employ to help out. But...I'll cover that in a subsequent post.

Next, we'll switch gears and look at the various options available in the project management software market. That may seem obvious, but most people are confused by the breadth of tools available on the marketplace. I will simplify this for you by helping you organize them into five categories, and help you identify the category (or categories) that best fit your organization.

After that, we'll look at some strategies and tips to actually implement software and gain strategic advantages from it.