Would you like some EPM with that?: white paper

This white paper is part of our "From the trenches" collection. It discusses the evolution of project management systems, the use of Enterprise Project Management, and the importance of understanding which project management solution is best for you.

To download the Word version of this white paper, see Would you like some EPM with that?: white paper.

To see more white papers, see "From the Trenches" white papers.

Would you like some EPM with that?

In my office recently one of our most experienced employees came to me with a strange question.

"How do you know if something is a project management system?"

I opened my mouth to answer then paused … for a long time. The answer is not obvious.

In the early 1980s the first critical path scheduling packages became available for personal computers. In fact, I find it interesting that history shows that critical-path scheduling software has been one of the first commercial applications published in each wave of computing starting back with the first commercial mainframes in the 1960s. My start in the project management software industry dates back to the early 1980s though and we would have used the terms "project management software" and "critical-path scheduling software" synonymously.

In 1983 if someone had shown me anything but a critical-path scheduling system and asked if it was a project management system, I'd likely have shaken my head and said no.

Microsoft Project at its core is a critical-path scheduling system and we still use the terms project management software to describe it. So if someone were to ask me "Is Microsoft Project project management software?" I'd feel pretty comfortable answering in the affirmative.

But what about accounting software? Several Dynamics products do project budgeting and cost tracking. Is that project management? I'd have to say that it is.

SharePoint products allow you to manage documents and document workflow and make lists of outstanding issues. Is that project management software? It sure sounds like it.

Microsoft Dynamics CRM allows you to attach activities and resources to client initiatives. Isn't that project management? It certainly could be.

How about contract management, timesheet management, workforce scheduling, material consumption and equipment usage management, and production value tracking? Are any of these project management? Yes. Any of them could be.

Years ago I worked with a specialist in construction project management whose main tool was something that managed the pace of work of several trades simultaneously. This single graphical report tracked carpenters and plumbers and electricians and several other trades. This very experienced project management showed me how just managing the pace of work from one team to another avoided electrical teams arriving to an area before the drywall was erected and kept the plumbing team from overrunning the electrical team. This single report for this particular type of project allowed this project manager to be remarkably effective. Was that a project management system? You bet it was.

To make matters more complex, we have both project management tools that make individual project managers effective and other tools which are more appropriate to the organization. Enter "Enterprise Project Management" software. To be fair, the concept isn't that new. The first project management systems in the 60s and 70s were all enterprise tools, though access to computer systems in general was much more restricted then for most organizations.

Like all good things, Enterprise Project Management resolves to a three letter acronym: EPM. If I do an Internet search for EPM, though, I might find Enterprise Project Management. I might also find Enterprise Performance Management, Enlisted Personnel Management, Electric Propulsion Motor, Exchange Permission Manager or any of about 40 more definitions. Make sure you're looking for the right one because a propulsion motor is unlikely to help you with project scheduling.

If we have difficulty defining a project management system, it's certain that we'll have even more difficulty defining what makes a project management system an "enterprise" project management system.

In the end, is it that important?

I've been known to say for some time that I always prefer to define the problem before we start looking for the solution. Our office often gets calls asking for help deploying an "enterprise project management system" and inevitably I must ask about both what they mean by "enterprise" and what they mean by "project management." It takes a minute or two for some to get over having to explain themselves. After all I have some background in project management and they're certain that I must know what these terms mean.

Sometimes I find out that the "enterprise" is in fact a handful of people. There's nothing wrong with that. I run a small company myself and no size is too small. But not asking might have had me recommending software that was designed for company of 1,000 people, and while I'm sure it would look lovely, it would be a complete disconnect between tools and requirements. Plus, the return on investment of such a deployment would likely be awful because of the difficulty in paying back such a disproportionate investment with efficiencies of a small team.

If you want to give advice on tool selection, not only is it important to get the scale right, it's critical to determine what the business challenges are.

A number of years ago, I visited a very large power authority where we had built up a good reputation for assisting with deploying project management software. During this visit, I met with the head of a new department who wanted to deploy "enterprise project management software". I sat with him and went through his requirements.

"How many projects do you have?" I asked.

"Ten to twelve at a time," he answered.

"And how many tasks would you have in these projects?" I continued.

"Oh, it's always the same. Six tasks," he replied.

"Six," I repeated. "So, we're talking about 60-70 tasks to manage at a time?"

"Yes, that's right. It's very complex," he said.

"I understand," I said. "And how many users will be involved in managing these tasks.

"It would just be me," he answered.

You can see this coming, I'm sure. There was no critical path, no issue management, no document management, no resource leveling, no risk management and no cost management required. All he needed was a visible guide to outstanding tasks for himself so he didn't let something drop through the cracks inadvertently. The amount of money on these projects was actually huge, in the millions of dollars, in fact, but the unique type of project meant that managing it was relatively simple.

"Why not just put them on a white board here in your cube? I suggested. You could use some permanent marking tape to make rows for, say 15 projects and then use colored dry markers to update the schedule and it would be right in front of you. You could use a red marker for example to make a note of important milestones and a green marker for tasks with a long lead time."

He seemed quite perturbed and upset even that I couldn't recommend a large enterprise piece of software to manage his projects. He'd heard from others in the company that there were great enterprise project management packages out there and was sure I'd come to him with a recommendation of deploying one.

The meeting wound up shortly thereafter and I was sure I'd left an unhappy new contact behind. To my surprise he called my cell phone a half hour later while I was on my way home.

"Thanks so much for the meeting," he started. "I've already ordered a white board from the office supply department but if you could spare a minute, could you go over with me again which color I should use for which kind of tasks?"

Fifteen minutes later he had taken copious notes and was a happy camper.

It was a great lesson for me which I've carried to many more engagements. I try to take that extra minute early in an engagement to determine what is meant by terms that deceptively sound like a universal standard.

Project Management software could be represented by numerous categories. If we just start with the Project Management Institute's Project Management Knowledge Areas we'd end up with:

• Integration Management

• Cost Management

• Communications Management

• Scope Management

• Quality Management

• Risk Management

• Time Management

• Human Resources Management

• Procurement Management

It's easy to imagine a variety of tools, packages and techniques for managing any of these areas, and, depending on the particular situation, any one of these categories could produce the most significant improvement in project management or project management across the enterprise.

Let's say an organization has project communications challenges; perhaps its resources are spread across numerous time zones and countries and even companies. In that case, it would be easy to see how you could deploy Lync and SharePoint to make a huge improvement in communications.

If an organization deals with many sub-contractors on its project or if it has a large purchasing component in its project, then strong procurement management with a Dynamics ERP and SharePoint might make the biggest difference.

If the organization is complex or of larger size and the project challenge is prioritization and resource capacity planning, then perhaps Project Server is the fastest path to a return on investment.

Remember that staff person asking about how do you know if a particular package is project management software? My answer was this: "Is it software? Does it apply to managing projects? Then it's project management software. Now go back and find out what the client's project management business challenge is."

Articulating your project challenge before deploying your project solution will always yield better results.

About the Author

Chris Vandersluis is the president and founder of Montreal, Canada–based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (http://www.epmguidance.com/?page_id=39).