It’s finally been announced.  The next Microsoft Project Conference will be March 19 to 22 in Phoenix, AZ.  Details can be found on the Microsoft Project Conference site at: www.msprojectconference.com.  Such conferences include a mix of marketing and technical information of course, but with a couple of thousand people gathering together in one place, it’s a good spot to learn tips and techniques on Project and Project Server from the many users and experts who attend.  I’ll almost certainly be there.

We spend a lot of energy in project management circles trying to determine how to do a thing. In my travels to various parts of the planet something that’s sadly lacking in many places is good judgement on whether we should do that thing.

I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. Yet, I was less happy when I heard the reason why the customer felt that their existing system was no longer able to meet their requirements.

“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. Because they need 3 rate values and our existing timesheet can send only two we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you that with your TimeControl?”

TimeControl was certainly capable of sending multiple rate values, I assured the specialist but I was at a loss to understand why they needed such an interface in the first place. In the end, after some discussion, the client agreed to pay for a day of system design and I scheduled some time in the offices.

Our meeting together started off just great. They had the CIO in the room and I was suitably impressed that the head of the IT department was sufficiently interested in the problem to attend himself. He and the technology specialist took turns white boarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic white board marker colors all over the board.

I took copious notes.

By the break though I had my first intelligent question. “What was the volume of transactions,” I asked, “that was being handled through this manual process?”

No one knew the answer.

“Can we ask the CFO?” I asked.

A quick call was made. Yes, the CFO was keen to talk to me but could only do so over lunch. I was delighted. Senior management intervention at such a rapid pace isn’t that common and indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the white board diagram. I headed to lunch with the CFO, the CIO, and the technology specialist that had called me originally with a good understanding of what they wanted and the kind of time it was going to take to create. The CIO and I agreed that changing the timesheet was fundamental to the new solution and that 6-8 weeks of developer time to automate this “archaic manual transfer process” sounded quite reasonable. I was upbeat. Sounded like some business on the way.

Yet, there was something niggling at the back of my mind. The whole premise of the problem came back to a lack of a single field in the old system and its inability to move that column of data to the Finance system. I’d already determined that this data was critical to the corporate effort “Why not just give up on that extra data,” I’d asked. “What would happen if you just didn’t transfer the data?” The CIO had told me he’d already considered just that and that management had made a good case for this data being essential to their ability to bill accurately.

Time for lunch. We went across the street for chicken. (Business lunches always seem to be feather, leather or fish!)

I sat across from the CIO with the CFO to my left. The technology specialist was across from him. We exchanged pleasantries and then ordered and while we waited for our meal, I turned to business.

“I’m here to work on this timesheet system to finance system interface,” I explained. “The CIO here and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

The CFO to his credit describes exactly what we’d been talking about all morning. This was a good sign. Often when you go back to the client or end user of a system, the understanding of the requested change isn’t at all what IT understands.

“Now could you describe how you handle the interface now,” I ask.

“It’s an archaic manual intervention,” he describes. Again, sounds just like what I’d heard this morning.

“And how many transactions are managed through this archaic manual intervention?” I ask.

“Oh about 5 a month,” he says.

There’s silence at the table.

“Five,” I repeat. I see the CIO’s jaw drop out of the corner of my eye.

“Yes,” says the CFO.

“And how long does it take to do these transactions manually each month?” I ask.

“Oh, it takes one of my staff about 20 minutes,” he says.

“Excellent,” I say, my heart sinking as I changed the subject.

The CIO couldn’t meet my eyes. We finished our meal and headed back to the office as we did so, he walked next to me. “I’m so sorry for wasting your time,” he apologized.

“No need to apologize,” I said. “I’m just happy we figured this out before spending 8 weeks on writing the interface.”

The time to recoup a return on investment from the effort we’d described would have been many years. At 20 minutes a month there was no point in doing the work. In fact, the company had already spent way too much time working on how to do it already.

Could we do the work? Sure. But we shouldn’t.

And sometimes that is the most effective project of all.

“So, what were you trying to accomplish here?”

It’s a common question that I’ve had to ask of many project management office managers. Because of my background in enterprise project management systems, this mostly happens in response to some request to review a problem with a project management system implementation. Over the years I’ve been called upon to try to fix, repair, re-establish or just replace a failed or problematic project management system and my approach is always the same:

1. Tell me what’s going on?

It’s a good start and it gets the problems and the client’s frustrations up on the table right away. The story typically comes out in a jumble. (Think Pulp Fiction where the story starts in the middle and then jumps to the beginning, back to the middle, to the end and then finishes back somewhere in the middle.)

2. Distinguish the parts

I’m never presented with a single problem. Inevitably before the problem has been fully described, it’s more than one problem and it’s critical to distinguish out each of the moving parts. I’ve had lots of experience debugging system’s problems and anyone who has ever been in that role will tell you that it’s important to try to isolate the problems and then isolate the causes.

3. “So, what are you trying to accomplish here?”

Now that I have a fuller understanding of what is upsetting the client, it’s essential to know what they want to accomplish and therein lies the expectations of the client.

4. Design the solution(s)

The solution is often not obvious and determining the expectations often changes where to look for satisfaction.

Let’s take a look at each of these 4 steps in a bit more detail:

What’s going on?

When people describe a project management problem from a systems perspective the most typical description sounds like this: “It’s just broken”, “It just doesn’t work”, “It’s got a bug” or “The data is corrupt”. None of these of course are helpful. So we start by asking for specifics. “What did you see that makes it look like it’s broken?” , “Can you re-create the steps that make it look like it’s broken again?” , “Can you show me a report or a screen-shot that made you think it was broken?”

This sometimes slows the process down. Remember that the ‘What’s going on?’ process often arrives in a jumble and we may be looking at multiple problems. When the client can finally show me the report, field, screen or result that they believe to be a problem, the next obvious step is to ask, “What do you believe the result should be?” During this part of the analysis I’m often fascinated as how people produce results. I’ve seen people take information from a project management system, extract it to Access or Excel, manipulate it with macros, formulas and then extract it again, merge it with data from other systems and then point me to the end result and say “See? It’s wrong!”

Think that’s unusual? It’s not. Excel remains the most popular project management tool by far and project managers often have more experience in it than in whatever project scheduling too they’re using.

Distinguish the parts

When we get the offending result identified and I can determine that it is, in fact, not the result the client was expecting, it’s key to ask “What other results are not appearing as you expect?” Often there is one part of the data or the process that is the most problematic for today but there are other results that are only a minor irritant yet may have bear a significant impact on the problem. For example, I had a client who was unhappy with the resource levelling results of a project management tool. “Is there annnnyyyyyttttthhhiinnnnngggggg else?” I asked. Well, there was. There had been a minor irritation with how individual resource calendars were updated when vacations were taken. That opened up the door to how resource availability was defined and before you know it, we’ve got a fundamental break in the resource definition process as the main culprit. We standardized that process and how an individual resource’s availability was defined and presto – the scheduling results were all perfect.

So, what are we trying to accomplish here?

The answers to this question often amaze me and you’d think I couldn’t be so surprised after almost 30 years in the industry. The most likely easy answer is “We just want enterprise project management”. Of course I then have to ask what they mean by that. On many occasions lately what I hear is “We just really needed a timesheet”. The client has purchased an entire resource management, schedule management, portfolio management analysis system and then finds that the timesheet aspect of what they purchased just doesn’t give the results they were expecting.

It’s also common to find that the education of working on an enterprise project management system deployment has changed the perspective of what they really need. Perhaps they were enthralled by the sales demonstration before they got started. Perhaps they didn’t really understand what questions they should be asking. Perhaps more knowledgeable people were hired only after the deployment started. Either way, the notion of what’s now required evolves and by the time the client calls me to help get their project management environment back on track, the expectations of the original system are quite different from what they were before we started.

It’s also very common for the client to have gotten so caught up in the minutiae of system issues that they’ve lost track of what the original goals were.

This often brings us to a challenging aspect of the repair project. What if the new goals of the enterprise project management environment would be better served by not continuing to deploy the system they’ve already got a lot of investment in? We’ve had a couple of cases where the client was trying to deploy an entire enterprise project management system but in the end just wanted a timesheet. Do we keep banging the square peg in the round hole? Or, can we put that enterprise system aside for now and just deploy a more appropriate timesheet? Now, that’s a situation of going from a more complex system to one that’s less complex but I’ve seen the reverse as well. Someone takes a simple internal timesheet system and then tries to modify it with every enterprise project management feature they’ve envisaged. At some point it makes sense to pause that work and rethink the whole tool selection.

Build the solution(s)

I’ve been talking a lot about tools but often a solution can be found in the process. It’s common to find that some process that evolved over time or that is engrained in the corporate culture is the root cause of data analysis that makes no sense. Once we know what the client needs are, we can go back to the source and start with a solid process for collecting and analyzing the data. What the client originally thought of as a tool “bug” or “corrupt data” is often resolved with a change in how data is collected, in how it’s interpreted, with training or just by saying “don’t do that anymore” (I can’t tell you how many times I’ve had to say that).

It’s also possible that we can produce a result in a manner that the client hadn’t thought of. Once we know what the client is trying to accomplish, there are often a number of ways to get there that the client simply hadn’t thought of. From time to time, for example, I’ve had to say, “Why bother automating that? We can do it manually in 10 minutes per month with a lot less stress.”

If you take a methodical approach to solving issues that are a challenge to your enterprise project management environment, you’ll find that most of them are solveable very quickly. When it turns out to be expanding into a more and more complex problem it’s often good to take a big step back and look from a higher perspective. Figure out what you’re trying to accomplish, what benefit that will bring you and then how you’ve been trying to get there. When you break the problem down to its component parts and you can see clearly where you need to get to, building a path there is easier.

One of the first things I need to do whenever I go into a company to talk about Enterprise Project Management (EPM) is to get some kind of a consensus of what it means.

I can hear some of you laughing.

“Surely after all this time,” you’re saying, “we have a common understanding of such a basic term in the project management industry.”

No, I’m afraid not. It’s perhaps remarkable in an age when we talk often about Project Management Maturity Models but a common understanding of EPM is not only not that common but there is a huge range of possible interpretations.

EPM for some means everyone storing their data on projects into a common repository. For others, it means grouping projects together which share some common element, perhaps a resource pool or inter-project dependencies. For some, EPM means working on projects at a portfolio level. Still others might mean tracking actuals in a single timesheet. There are people who say that it’s not really enterprise project management unless you’re doing resource capacity planning and there are people who say it’s not “enterprise” unless it’s integrated directly to the Enterprise Resource Planning (ERP) system.

That’s already a lot of possible directions to go and yet there’s more. The sheer size of what someone might mean by “the enterprise” is also critical. In the last month, I’ve been in organizations which thought of an enterprise as being a division of 50 people, a complete company of 400 people, a division of more than 1000 people and a department of about 10 people.

So, all of that to say that there are a lot of definitions of what Enterprise is and what Project Management is and what Enterprise Project Management is.

So, let’s transpose our definition conundrum to selecting tools. There are many vendors in the project management industry who promote their “enterprise project management systems”. This can present a challenge to those trying to find a tool to help their project organization to become more effective.

Microsoft is an excellent case in point. With the release of Office 2007, we see of course, the release of the new version of Microsoft Project. There are now 6 products to purchase from the Project department of Microsoft. Project Standard, the trusty veteran has been with us now since the early 90s. Project Professional 2007 is the big brother of Standard designed to link to Project Server. Project Server of course is now in its third iteration and its associated Project Web Access. There is also Project Portfolio Server 2006 for Project Portfolio Management and the associated Project Portfolio Client Access License. I’ve seen organizations which use Project Standard as a solution for their enterprise requirements so, while it is designed as an individual efficiency tool, it’s certainly possible to work with it either alone or in concert with other tools to make an entire organization more effective. Project Server of course, is what we’ve heard most of from Microsoft in the last 4 years for organizational solution needs.

Yet, there are a couple of elements that Microsoft has also released recently that are fascinating possible solutions.

Inside of the new version of Microsoft Office SharePoint, a product which is provided at no additional cost as part of Windows, Microsoft has included “Lightweight Projects”. This template allows an organization to create simple GANTT charts complete with dependencies, resources, Critical Path analysis, and a bar chart view. The module was actually created by the Microsoft Project development team for the SharePoint group. Lightweight projects can be promoted to Project Server 2007 at any time should you need to put them into a more complete structure with more depth and options but for some groups, this will be an interesting feature to look into.

Of course there are already organizations which have used SharePoint’s other features to track project documents, issues, risks, to-do lists and more. For them, this may be enterprise project management. Here at HMS we’ve assisted organizations with creating enterprise management systems for tracking key project data using only SharePoint.

The most popular project management system in the world (yes, I’m talking about Excel) has also been enhanced with Office 2007. In particular a server component for Excel which is part of the Office System 2007 is something that project management Excel aficionados should look into. The server component allows the massive Excel farms that have been so problematic to support to become centralized enterprise-like components. Where once we would have thought of Excel only as an individual productivity tool, that thinking is due for some revision with this new version.

Microsoft also has tools for project management that are part of its Dynamics line if you think of project management as an accounting or cost-based conversation. And, if you’re in an IT environment doing development, then the new Visual Studio Team Services system is a centralized enterprise-level system which includes scheduling and resource allocation.

But, by far my favourite of the new products in the Microsoft camp is Groove. Groove was one of Microsoft’s acquisitions this year. Whether you’re talking about Groove Server or the Groove client, the Groove Project Space is a fascinating way to collaborate with a team. Documents, lists, assignments and more can be assembled in the Groove space which can interact with SharePoint, with the Groove Server or even peer to peer.

I’ve talked only about Microsoft so far but there are offerings from numerous other vendors for systems that are worth consideration including Primavera, eProject and others. So, which of these various tools are the best? Just as I’ve often said in these pages, there’s no way to answer the question. If you’re looking for a solution, you’ve got to first identify the problem. For any organization which identifies business challenges at the enterprise level that require an enterprise project management solution, the first step is to identify exactly what that business challenge is.

When we consult a client on EPM, we go through a simple yet powerful process with the management of the organization early on in the deployment. We start by having senior management identify key business decisions that they either can’t make now or can make only with great difficulty that they believe would be made easier through the deployment of an EPM system. The exercise is virtually always fascinating. Once we’ve identified as many possible such business challenges we trace what would be required to deliver information to management in order to make that business decision easier. Then we sort the requirements based on those which are possible to deliver based on data that is already available to us and those which will deliver the biggest impact on the organization.

There are a couple of instant benefits to this process. First participants in the meetings are almost always surprised to find out that the perspectives of others in the meeting don’t match their own. Just finding out that others in the organization are not looking at the same metrics or trying to manage the same business challenges is usually eye-opening for everyone in the process. Second, we are able to focus on what aspects of an EPM system should be deployed in order to deliver the fastest return on investment. I have never done this exercise where I have not been surprised by at least some aspect of what was revealed.

There is a plethora of enterprise project management tools on the market and if you’re thinking that implementing one of them will result in making your organization more effective, then start your search in house. Start with identifying what aspects of your business will benefit from what type of system and the selection of which category of EPM tool to search for will become infinitely easier.

How can you ensure success of deploying  an EPM Solution like Microsoft Project Server?

I own a company that does deployments of Microsoft’s Enterprise Project Management (EPM) Solution. To be fair, HMS Software does more than that. We’re also an ISV but I spend a fair amount of my time working with mid to large organizations on how they can deploy EPM. Some of the challenges are specific to Microsoft’s technology but many of them are similar to what I’ve seen companies face since I started in the project management software business in 1983. We’ll look at how you can plan your own EPM deployment here.

One of the biggest challenges we face when we start an EPM deployment is establishing a credible roadmap for producing the intended result. While we have done enterprise project management systems deployments here for over 24 years, one thing that hasn’t changed is the desire of senior management to have all the results yesterday.

The challenge is compounded by a couple of factors that are almost always present:

1. Sales has shown the client the end-result without explaining the effort that would be required to reproduce the effects in a production environment or even how much effort went into creating the virtual image and data involved in the sales demonstration (typically several man-months).

2. Microsoft carries an ease-of-deployment legacy. People have gotten used to stuffing a DVD into their PC, waiting until it pops out and then getting the benefits of the software they’ve purchased immediately. Oh, there may be some notion of optional training but there is rarely an expectation that what is being undertaken is an organization-changing exercise.

What is Enterprise Project Management?

That would be challenge enough but there are other aspects that are often overlooked by the client during a purchase starting with ‘What exactly is EPM?’ That’s a short question with a potentially long answer. In the early stages of an EPM deployment we will do an envisioning workshop with the client’s senior management. One slide that I always use looks like this:

“What is EPM from your perspective?” I’ll ask. The responses are often found in one of the circles on the slide. The responses might be:

Basic Project Management

“For us, enterprise project management would mean that everyone would be doing project management the same way and using the same tools.”

Enterprise Project Management

“That wouldn’t be enough for us,” someone might say. “For us, enterprise project management would mean that our project management data would be integrated. We would be able to get reports that would show our schedules in an integrated summarized report and we would be able to manage the impact from one project to another.”

Project Portfolio Management (PPM)

“It’s about project portfolio management for us,” someone might say. “For us, enterprise project management would mean managing one level higher at the project level. We would need to group projects into portfolios, report summarize and analyze them together. We’d need to be able to follow progress at that level as well as implement stage-gating.”

Resource Management

“For us, enterprise project management would mean resource capacity planning. We need to know not only if we can take on a new project and what the impact might be on existing commitments, we also need to know what the status is of managing the work we’ve already committed to based on project progress and resource availability. “

Reporting Analysis

“For us, enterprise project management would occur in the reports,” someone might say. “We need a report that pulls from project management, finance, HR and other internal systems to make roll-up reports for management and decision making. While we’re talking about reports, we’ll also need dynamic dashboards, scorecarding and other visible systems.”

Budgeting and Cost management

“For us, enterprise project management is all about the money. We budget at the beginning of the year. We then budget for each project and the only thing that matters for us is tracking the money against the plan, month after month.”

Timesheets

“Never mind the planning. If you could just tell me what my people actually spend their time on, we’d be so far ahead of where we are now, we’d call that an epm success,” someone often says.

Communication and Collaboration

“It’s not about the fancy algorithms. We need to facilitate talking to our people. Can you help us connect our project teams that now include not just planners but also senior management, clients, users, sub-contractors, outsourcers and team members?”

Integration with External Applications

“We’ve got a big ERP/Finance system which is great except that we don’t have any of the forward looking projections for deliverables and costs that come with project management. If you could connect a project management tool with our ERP/Finance system then that would be plenty of enterprise project management for us!”

Workflow

“We envisage a system that tracks not just tasks but procedures in an automated fashion. We’d like project managers to fill in an online form to request project funding which would then go to the person responsible who would then, in an automated fashion, accept or reject the request. If approved, the project would instantly be included in the EPM system. We’d like to do the same with all our project documents. In fact, we’d like to automate all our project management procedures in this way through workflow management. That would really be enterprise project management.

Business Intelligence

“What we need is scorecarding, dashboarding and data mining of our project data,” some people will tell us. That would be the ultimate Enterprise Project Management environment.”

The Project Management Maturity Model

“We’re working on improving our maturity level as measured by the ‘Project Management Maturity Model’.”

So, what’s the right answer? They’re all right. In fact, it’s probably not an exhaustive list. EPM can mean so many things to so many people and is highly dependent on the perspective you are looking at the problem from.

When we do this with senior management, what often happens is that there is no one of these aspects that is not desired. Yes, people want all of them. And, when they ask if all of this is possible in a Microsoft EPM Solution deployment, the honest answer is, “Yes”. The problem is, that each of these aspects of EPM can be considered as a vector or a direction in which you can push the EPM environment. If we decide to push on all of these vectors on the first day, the size of the project we’ll end up designing will be so large, so potentially disruptive, so complex and involve so many other corporate systems that it will have little chance of success.

Remember, an Enterprise Project Management deployment isn’t just technology. If it were, the implementation would be over in a few days. No, an EPM deployment involves Strategy, People, Process and Technology. Successful Microsoft EPM Solution deployments virtually always consider the project a ‘Change Management’ project rather than a technology project. What we’re looking to accomplish is to change the way the business works. How? Well, depending on which direction an envisioning exercise goes, the direction could be very different.

We know though, that making a huge project that’s very difficult to understand all of makes for a highly risky project.

EPM Deployment Approaches

Let’s talk for a moment about how many people approach an EPM deployment. There are a couple of possible scenarios

Big Bang

The Big Bang theory says “Let’s do it all!” The idea is that we’ll spend an inordinate amount of time designing, building, rewriting and programming the ultimate enterprise project management environment. It will take a phalanx of programmers and one day, sometime in the future, on a given weekend, we’ll flip a switch and everyone will have enterprise project management. If we were to graph this as Return on Investment over time, it would look like the picture at right.

There are pluses and minuses to using the Big Bang theory. On the plus side, there’s a better chance that with other types of approaches that the end result will be closer to the original intent. After all, the team doesn’t rest until they’ve checked off all the desires created at the beginning of the project.

On the negative side, however, there are a few big challenges. First of all, the organization doesn’t receive any return on investment until the project is 100% complete. That may be months or a year or more down the road. Every day that the project is incomplete is a day someone can wander through the building with a “better” idea. Also, the nature of life is that it changes. Any team change, management change, change in corporate mission or strategy, change in fundamental technology architecture, change in corporate ownership can result in the project being restructured or cancelled. If this happens, the organization receives nothing for its efforts.

The Instant Bang

When we talk about the legacy of instant gratification legacy that follows Microsoft, we see a different phenomenon. Some clients will assume that deploying the Microsoft EPM Solution is just like playing a Microsoft Game. We load in the DVD and a few moments later, we’re doing projects in a coordinated, collaborative fashion. The return on investment looks good for a few days or even weeks as the pilot group with the most excitement over the new system starts to use it. However, without the investment of the senior executives it is extremely difficult if not impossible to effect culture or behavioral change and the project rarely extends. The system stays in use for a short period of time and then is either abandoned or left in use by a tiny number of users who are often frustrated that they’ve been unable to entice the rest of the organization to work together.

The Phased Approach

We’ve found over the years that a phased approach is the most successful method of deploying an Enterprise Project Management Environment. There are a lot of reasons for it. Here are a few:

Ø First, the organization starts to receive a Return on Investment early in the process. This serves to safeguard the implementation and validates to management their decision to do an EPM deployment in the first place.

Ø Second, the deployment tackles whatever technical challenges in waves rather than all at once. As the complexity of the system grows, so too does the maturity of the organization in handling that complexity.

Ø Third, the deployment eases the culture change into the organization over time which is always easier. It’s a truism that change causes upset. That there will be some upset at such a change in managing projects is a certainty. Deploying the entire vision over time lets the users adapt to the different way of doing business.

Ø Finally, no matter how much time the organization spends in doing the original design, it is bound to change its mind as soon as it sees the system in operation. Getting that first phase of the deployment into production earlier lets the organization learn from it as they move forward.

The most critical element of this plan is the first phase. We instruct our consultants to determine “the most minimal deployment possible which will return an ongoing positive return on investment.” I’ve worded that very carefully. We want to find a first phase of the deployment that can be put into production that will provide results and that each week will give back more benefit than the effort required to produce them. If we do that, the deployment will last forever. No one would remove the deployment because they’ll say, “Oh, we can’t remove that, we get ‘this’ out of it every week.” If we’re successful creating that kind of deployment, we’ll be able to build on it in the months to come. If we’re not, the project and the deployment is still very much at risk.

Getting started with your EPM Deployment strategy

If I’ve made you think twice about doing an EPM deployment, that’s probably a good thing. Not that you should not do it but a successful EPM deployment always starts off with a bit of extra thinking. So, how should you go about doing your deployment? Let’s start with a few prerequisites.

1. The Project Management Office

If your intention is to deploy an enterprise project management environment, there’s no way around having an enterprise project management organization. This is commonly referred to a Project Management Office or PMO. You can call it whatever you want, but there’s got to be a central management of a system like the Microsoft EPM Solution. Who will declare templates to be the ‘official’ template? Who will determine who has authority to change resource priorities? Who will determine what a report will look like and who will have access to it? Who will decide whether to manage risks and if so, what process must surround it? And so on, and so on… No, a PMO is essential. If you don’t have such an organization (even if it’s one person) then you’ll need to start there as one of the earliest steps towards your EPM environment.

2. Executive Sponsorship

Next, get sponsorship and support from senior management. Whoever is supporting this project from the executive suite needs to know not only what the goals of the deployment are, but how long they’ll be required to provide support. We typically tell executives to plan for a minimum of a full year of sponsorship duties. One pitfall that we often see is a small group of middle management or project managers who desire an Enterprise Project Management environment but lack executive level support and decide that they’ll try to do the deployment themselves in order to get that support. It’s the Field of Dreams “Build it and they will come” approach and it’s almost never successful. The problem is, the very benefits that would be attractive to management (such as pm methodology compliance, global project reporting, resource capacity planning, and collaborative project management) are those benefits that can only be achieved with the participation of management.

3. We’re project managers – we don’t need project management!

If you want to avoid the most common pitfall to an EPM deployment, make a project plan. I know, that sounds strangely simple but it’s amazing how many EPM deployment projects don’t, in fact, have a project plan. One of the easiest pieces of advice we can give to organizations considering deploying the Microsoft EPM Solution is to make it a project and to apply all the same methodology they already use for any other project. Is there a project schedule; a budget; an executive sponsor; a project charter; resources; success metrics? These things might be found in every other project in the organization but, just like the shoemaker’s children who go barefoot, project managers often forget to apply their skills to their own projects.

4. Set goals

Work at the very beginning of the project to determine what the measures for success will be at each phase. Have a clear set of performance metrics goes a long way to helping not only the project team but also management focus on completing a phase of the project.

Getting started

If you’re wondering how to get started, here are a few suggestions.

Envision

Start with a facilitated vision session with senior management. If you use external assistance in no other aspect of the project, you’ll find it’s most useful here. Having someone who has been involved in several other EPM deployments is key to success. We’re not just talking about someone who has been a user of an EPM system but someone who has worked through some of the issues we’ve described above and who has a good understanding of both the capabilities of the Microsoft EPM Solution and the process of managing projects in an organization.

Who’s who?

One of the things you’ll need to decide on early is who is the ‘enterprise’. I’ve used that term several times in this article but the enterprise could mean whatever you decide. Is it your department, your division, your entire company? One common mistake made by people doing a deployment is making a plan for an entire company but only having authority over their own division. The hope is that others will come on board if the system is available. It’s a variant on the Field of Dreams approach and it makes for a solution that’s not attractive to those other divisions and not useful for the ones who you do have authority over. So, decide early who will be involved and make sure they’re included in the planning.

Make a Project Plan

Just like you would do with any other project, take the time to make a proper project plan. There are numerous plans available online that will give you guidelines on some of the subjects that you need to cover. They’re a good place to start but you almost certainly have all the skills required to make a proper project plan for an EPM deployment.

Conclusion

If you are considering or have started a deployment of the Microsoft EPM Solution, focus your deployment by considering these three points:

1. Treat this project as a project. Use all the skills you already have for managing projects to manage the Microsoft EPM Deployment project. Remember, it’s primarily a change management project not a technology project.

2. Break the project into manageable pieces and treat each phase of the project as a sub-project with its own success metrics, schedule, budget and resources. You’ll get some of the benefits of the overall system faster and that will serve to get even more support from management.

3. Remember that Return on Investment has to work at every level. It’s not enough to make a system that works for senior management but doesn’t work for the people who have to manage it. Or, a system that works for the project managers but doesn’t deliver the reporting required by senior management. Or, a system that works for the project managers and senior management but is too hard or too much effort for individual users. Each person who must invest time and energy into the use of the system should be considered in terms of their own return on investment.

If you’re designing a deployment that follows a phased approach and uses the basic project management methodology you already have for other projects, you’ve got a great chance of success. Good luck and happy planning!

Anyone who has worked with project management systems knows that the way you display data can dramatically affect the decions people make from it. This is why we often see GANTT charts with critical activities in red. I’m reminded of one of my very first sales of project scheduling software back in the 80’s. I don’t dare share the name of the organization but it was a large utility. We’d made this sale a few days earlier and now I got a call for “technical assistance”.

“I have a big problem. All my tasks are red,” the hapless client reported.

“Oh, that’s not a problem at all,” I replied. “Red tasks just mean that you are looking at the critical tasks. These tasks have been marked as red because they are on the critical path.”

“That’s another thing,” said my new client. “That word ‘critical’. That’s not going to work for us.”

There was a moment of silence. I was speechless. (For people who’ve met me you will know how unusual this is.)

“Perhaps the word ‘priority’ would be more appropriate,” I hesitantly replied. “Yes, that’s excellent!” said the client. “Now, what can you do about changing these colors? I need to get rid of these red tasks”

For those of you who have grown up with critical path methodology you might laugh. “This person needs training,” you might say. But I learned something very important from the interaction. My first reaction was to think that we needed to get in there right away and train people to distinguish between red tasks and blue tasks but I realized that the problem wasn’t his, it was mine. His perspective was that red tasks were a problem and that he’d have to take action to eliminate all the red from his report before he could give it to management. If you’re familiar with the critical path algorithm, this was going to be a problem because there are always tasks which are critical.

The challenge for the user wasn’t trivial. Even if I had trained him, he knew that his management would not appreciate the distinctions of critical vs. non-critical and would see red tasks the way a bull sees a red cape – they’d want to charge at them with as much force as they could muster.

When data moves beyond highly skilled users and into the hands of people who will only interact with it only occaisionally, choosing the display mode of the data is extremely important. In this day and age, the desire of management to get “real-time” dashboards and “live displays” of projects can lead to unhealthy project environments. Let’s consider the following very simple dashboard:

The situation here seems quite straightforward. Project 1 is running very late, Project 2 is slightly late and Project 3 is on time.

Showing this display instead of a complex barchart might be very appropriate to management. This display will draw attention to the schedule of Project 1. What should be done? Most managers would now query the project manager of Project 1 to ask why the project is late and what can be done to get it back on time.

That’s great so far. But next week when management sees the same report, is the same action appropriate? Probably not. Just having displayed the dashboard once has changed its context. If we display the identical dashboard with identical results next week, management will be likely to ask a very differerent question: “Have things improved since last week?” The display doesn’t show this.

So, we have the same data, the same author of the data, the same display, the same reader of the data but the reaction is quite different. This is because the context is very important. The manager of the project system has a couple of choices now. He or she can make a report that shows a year of icons for this display so the time factor can show management when the task becomes red and then goes back to the yellow caution and hopefully then to green. Or, they can try something like this:

Now both Project 1 and Project 2 are significantly behind schedule but we’ve added a new indicator to the graph. Now the trend of the scheduled delay is displayed. The eye naturally goes to the two red Projects: Project 1 and Project 2 and then to the right where we see that the trend for Project 1 seems to be improving and the trend for Project 2 seems to be getting worse. Also a concern is now Project 3 where the schedule is still on time but the trend is very much in the wrong direction. It looks like resources have been pulled from Projects 2 and 3 to work on Project 1 which is improving at the cost of the schedule of Project 3.

This is all still pretty good at the moment but you can see how the paradigm of such data expands exponentially. There is nothing quite so attractive to senior management than colored dashboard indicators and there’s a whole industry of people making indicators and formulas to drive them. In the simple example above, new indicators might be ordered up in a heartbeat. Was the improvement in Project 1 actually done at hte cost of Projects 2 and 3? What was the relative return on investment of working on Project 1 instead of 2 and 3. Perhaps this Red indicator caused us to move resources from our most important client to our least important internal project. How was the move of resources to respond to the red “X” in Project one aligned to our strategic goals? What did it cost?

Before you know it we’ll have a page full of symbols, curves, flashing lights and glowing buttons. There are a few other things missing from the whole display that are often overlooked. They can be summed up as timeliness and completeness.

Are we looking at all the data? Perhaps the project schedule is showing late but only half the tasks have been updated and when the data is all collected, the indicator will turn green. There’s no indicator in this simple display about how complete the data is or isn’t.

Is the data up to date? Perhaps Projects 2 and 3 were updated yesterday but Project 1 was only updated 90 days ago. Should they even be displayed on the same page? The data might no longer be relevant when compared from one project to another yet there is no indicator on the display that the data is all homogenous.

When we create display systems such as dashboards and summary reports we have to consider these things. I have a couple of basic rules about dashboards:

1. Less is moreJust because we can measure a thing doesn’t mean we should. Imagine a page with 500 colored indicators with 100 different shapes being used. That’s obviously visually stimulating but will it be useful? Almost certainly not. Yet, a page with one color on it (just red for example) isn’t useful either. That tells you to get into action but not where.

1. There must be actionEvery indicator should be able to have a related action to it. E.g. If the traffic light is red and the arrow beside it is red, then the VP must call the project manager immediately and review an action plan for getting back on track.

1. The indicator must have qualityWe have an expectation that project data that is reviewed by management has already been approved in some way. Yet management often asks for real-time dashboards that shows data long before it’s been reviewed or approved. Showing the quality of the data by either showing the level of approval, completeness or timeliness right on the dashboard or through some other process is key to being able to count on the decisions that will be made from the data.

1. The indicator is made for a particular audience.Making graphics dashboards with colored, animated flashy graphics is fun and, in this day and age of technology, not that hard. Designing such a display that makes an organization more effective is much tougher. So, every display we make is written with a particular audience in mind. Who will read this display and what is their context for the data.

The way you display data and what you display can make decisions and action possible that was impossible in the past. By the same token, a badly designed display can cause decision makers to make the incorrect decision inadvertently. So, think about what action such displays will cause as you’re designing them.

If you’re implementing a project control system, or any enterprise-wide system, one of the most significant elements to consider is the product champion. Without a knight (of either gender) to champion the cause, the chances for a successful implementation drop dramatically.

So what is a product champion? It’s a person who is held to account for the success of the system implementation. It’s a person who on a given day stood up and said, “You can count on me. I’ll make sure that this system works for us.” A champion, just like a Knight of the Round Table has to be backed by the king. Without any authority from management, few people would (and no one really should) take on being accountable for a system implementation project.

There are several key elements to implementing any enterprise-wide core system which could handicapped or even block a successful implementation. We see this almost every day in deploying our enterprise timekeeping system or project management software.

These elements include:

Lack of Planning
Can I say this enough? Make sure you manage the implementation of your project management system with a project plan! We estimate that 4 out of every 5 implementations are attempted with little or no planning whatsoever. Without a project plan, the chances of being successful are slim. Without clearly defined goals, a well thought out budget, a manager who is committed to achieve those goals and management support for making the plan work, there’s little hope of getting anywhere. One of my favourite Chinese proverbs says “If you don’t know where you’re going, any path will take you there.” If there’s no clearly identified goal that everyone is committed to then how could you achieve it?

Duration of the Plan
There is an illusion that a project management software implementation (and many other enterprise systems) are complete as soon as the software is purchased. For anyone who has been involved in deploying such a system you know that purchasing the software is usually just the start of the most difficult aspect of the implementation process. If there are unrealistic expectations that the project will only last a few weeks, or a couple of months, then as the implementation drags into its sixth or seventh month, it may lose critical support. An enterprise-wide implementation for a mid-sized company can easily last a year. ERP implementations are often targeted at 2-3 years. This can test the most patient of supporters. Without the champion keeping the project alive, keeping people enrolled in the project and keeping the group enthusiastic about the end result, focus will ultimately be lost.

Lack of long-term support
Many things can affect long-term support for an implementation project. Management changes where responsibility shifts from one manager to another can be a key factor. Staff changes which change the composition of a selection committee or removes a key resource can have a dramatic impact. Before the process even starts, it should be made clear that the people signing on are signing on for the duration and are made aware of how long that support will need to last. A Product Champion may be the only continuity in a project which sees many changes around them. It is their responsibility to keep the project on track.

Lack of Focus
When you’re starting your system-wide implementation project, everything will seem very simple. After all, the core team who are starting the process will be comparatively simple to bring to a consensus on varying issues. Once the deployment of the system starts however, life will take a dramatic turn. Suddenly every personal, individual, conflicting interest in the organization surfaces as “must-do” requirements. Interests which for a variety of reasons will be defended to the utmost by the people who support them. It is here that focus will become the most important aspect of the implementation. Without a central figure to reaffirm the project’s goals, these divergent interests can drag the project right off the rails.

Power sharing
While I’m sure this is not an issue in your own organization, I must confess I’ve seen this occur in some organizations across the country. As it becomes apparent to people throughout the organization that the enterprise-wide system will actually impact them, some people will perceive this as a threat to whatever “power-base” they’ve created by using their own personalized systems. These people may have a great resistance to fully participating in the new system. Those who are very public about their concerns are the easiest to deal with. The most difficult (and I’m confident that most of you have never experienced this) are those who publicly proclaim their support of the system while in the background do just the opposite. The only way of overcoming this phenomenon is to have a central person who enrols or re-enrols these people in the vision for the whole organization, in the benefits for everyone that will come from cooperating. Someone who has the knowledge and authority to resolve their concerns. The person most invested in making this work is always the product champion. This particular subject is dealt with in much more detail by Peter Senge in his book “The Fifth Discipline”.

All of this points to a single solution; an individual who will hold the goals of the project against any and all resistance; someone who believes in the project and who knows they will deliver; someone who has both the desire and the support to make the project successful.

“Oh wait,” you say, “we’ve got just the thing. Our implementation committee are absolutely committed to the project and include all kinds of skills. Surely this is even better than your ‘product champion’”.

Sorry. Not so. A committee is one of those entities with many legs and no intelligence. It almost always results in management by consensus or worse. The keyword here is accountability. You can’t hold a group to account. You can make them responsible but there’s no way to hold them to account like you can with an individual. If you’re an executive sitting with your implementation committee and wondering if the project has any chance of making it your request should be this, “Would the person who is ready to personally promise me that this implementation project will be successful please stand up.” That’s your product champion. Don’t get started without them.

Given how project management software has taken advantage of today’s graphical age, there is a plethora of possible reports available for users of such systems. I’m always amused when we put such things as “200 reports included” or “thousands of reporting combinations available” in our marketing literature. Is this supposed to make people productive? As I work my way across the country and in different parts of th world meeting people who struggle with their own implementations of project control systems it’s easy to see why a system with hundreds of reports could be at once a great system to implement yet overwhelming for virtually all users.

When you start to distinguish the different kinds of audiences for these project management reports and the different kinds of reports available, the deployment of these systems makes a little more sense. Let’s start with the different types of audiences.

First of all, the users alone are an insufficient definition of the audience for the output of a project control system. These full-time or power users must be included, of course, but almost always, the users of a scheduling system are users at all because of the request or requirement of someone else. The users however will require detailed reports that allow them to identify work, debug input into the system, sequence and organize raw data into identifiable categories and orders and analyze the results of any analysis. In addition, this group will need to validate any other reporting into the system.

Another clearly distinct level of audience is the grass-roots input to the system. Some of these front-line personnel might use the system or use a “lite” level of access to the system but they will not typically be full users. The interest at this level for detailed analysis of the schedule will be low. Users at this level will be more interested in lists of tasks; in turn-around documents or forms to fill out while in the field and in simple schedules of what is expected of them next. How the system actually figured out what is expected next is of little use to them.

The ultimate ‘clients’ of many project control systems is another identifiable audience and that is the ‘Executive Suite’. Here the interest is not in the detailed analysis but in the synthesis or results of that analysis. Reports are expected in summary form with the all too elusive “One-Page Report” or an executive Dashboard being the ultimate goal for most executives. Trying to impress executives with a 20-foot flow chart of activities which stretches around 3 walls of the conference room will generally be unsuccessful.

There are likely several other potential audiences for project control reports. Project sponsors for example or the client themselves. Regulatory authorities often have specific requests and, if you’re in the defense business anywhere in the world, you’re likely to run afoul of Earned Value reporting standards. For each group of readers of the system’s reports you’ll need to look at their requirements separately.

Let’s turn our attention now to the kinds of reports which might be requested. Every project control system will have different types of standard reports but virtually every one of the systems on the market at virtually every skill level will include the following categories of views or reports: List reports sometimes referred to as spreadsheet reports, Barchart or Gantt views, Curves and Histograms, Activity Flowcharts, sometimes referred to as PERT, CPM or Network Logic diagrams, and Work Breakdown Structure (WBS) tree diagrams. There are a number of other more esoteric categories (scatter diagrams for risk data for example) and a variety of hybrids of different views but this is plenty for the moment. Let’s take these categories one at a time.

List or spreadsheet views are essentially text-oriented reports. These reports are organized in rows and columns just like a spreadsheet (hence the name) and these days are just as likely to look just like a spreadsheet when they’re output. Spreadsheet reports are useful for pretty much every audience depending on their content, their level of summary and the amount of data on them. A few products offer multiple lines of data per activity, most allow columns to be customized but only in one line per task. For executive reports, look for data to be summarized to a level of one line per project.

Barchart reports are sometimes referred to as Gantt reports. (After Henry Gantt who is credited with inventing them.) These reports are organized with tasks or summary tasks on the left with various columns of data and a bar or multiple bars against a date scale to the right. With abilities to modify what bars refer to what level of data, many different effects can be created here for different audiences. Typically, this is a good tool to use at the executive level if the system is capable of summarizing to one line per project and at the grass-roots level for individual schedules. Power users won’t often use a barchart except to validate that the schedule “looks” the way they’ve designed it.

Flow Charts are sometimes inaccurately referred to as Logic Diagrams or PERT charts after the charts designed for the PERT analysis method which is seldom used anymore. They show data at a detail level with one box per task and a line between tasks which are sequenced in order. In a good-sized project, this can add up to a lot of paper if you output the data. Still, this is the absolute best way to view the sequence of tasks. The flow chart is best targeted at serious users of project management software as the information contained in each box can be confusing for anyone not familiar with critical path methodology theory (that’s the name for the algorithm most often used to calculate schedule dates). In any serious project, there’s usually a “war room” allocated for the project team which should sport one of these diagrams as wall-paper. It’s a great tool to use while updating the project as you’ll immediately see the impact on other areas of the project when you change progress on a task. Also, having such a report ensures that proper project management techniques are being used and that the system is not simply a “barchart painter” regurgitating dates already specified by management.

Curves and Histograms show cost, resource and risk data. As summaries they are useful for management, in detail they’re of use only to experienced project managers. There’s likely no one at the grassroots level who wants to see the resource levelled histogram of data.

WBS diagrams are hierarchical tree diagrams just like an organigram. In a work breakdown structure however instead of an organization breakdown, you’re showing the breakdown of all work on the project. WBS diagrams are used to clarify other data and as such are best targeted at the power user.

In the end the system that you create should only have a dozen or so reports that are used with any frequency. These reports may be standard, out-of-the-box reports or may be customized using the many tools to be found in project control systems these days. Rather than looking for a system which has more reports than the next one, look for categories of reports. Does the system support the kind of WBS you’d like to see and are the customization tools there to alter it to exactly what you need. Finally, in this graphical age, see if the reporting view you like so much is also interactive. Can you display your data in this view then manipulate the data right on screen?

It’s happened three separate times this month. In hindsight it’s obvious but it amazes me that large organizations whose staff should really know better continue to bite off larger enterprise-wide implementations than they’re capable of delivering. The problem is, to be sure, insidious. After all with “enterprise-ready” software hype available in every publication, you might be lulled into thinking that just choosing the right software means that everyone in your organization will instantly become an integrated machine with all parts harmoniously moving in the same direction. The problem is, implementing enterprise-wide software of any category is much, much more than the purchase of the package itself.

I’m sure no implementation starts out this way but, for the three companies who I spoke to about it this month, they certainly ended there. I’ll not name these firms but, you’d recognize each of them instantly. One, an insurance company, the second a financial organization and the third a telecommunications company. In each, the issues were similar yet distinct. Each of these firms has an interest in making themselves more efficient by implementing project-oriented software. Sounds simple enough but even in this sentence the mischief starts. “Has an interest”. Well, firms don’t really have an interest, people do and if a firm is large enough, it is represented by many, many, many people. Part of the problem with implementing any kind of solution that will affect everyone in the enterprise is finding out first, how the enterprise will determine its wants and needs. Should it use the democratic method? Everyone puts in a vote and the solution with the highest number wins? Should it manage by consensus? Dissenting voices are managed one by one until there is some kind of movement in a single direction? Should the decision be made hierarchically? The executive at the top of the food chain decides and everyone else follows the lead? The answer to all of these may be yes… or no. Each firm’s management, for each situation must determine what degree of seriousness to allocate to an enterprise-wide plan.

I/S managers who might have spent years cajoling, teasing, arguing, forcing, enrolling and trading with their fellow managers in an attempt to generate enough consensus to move an enterprise-wide solution forward are often given the full authority of management to implement such solutions. In the past year I’ve seen Boards of Directors actually make operational decisions on software and on implementation schedules, something that in the 5 years previous would have been unheard of. With that kind of authority, anything can be implemented.

Yet, not every solution carries that much weight behind it. How do other enterprise-wide solutions get chosen and implemented?

In the case of the insurance firm, a committee has been struck with a mandate from the highest levels of management. Yet the mandate wasn’t clear in how it should be accomplished. In this firm, a couple of mainframe-based applications run high-level project tracking for the finance group. The goal is to eliminate these cumbersome systems and replace them with more modern reporting systems. The first idea was to look for a commercial system which closely matched the existing functionality. Surprise, surprise, no one has exactly the functionality required in a single system. While the requirement specification was being created to even evaluate systems however, the project increased in scope. Why look for obsolete functionality, the argument went, when we could create a state-of-the-art enterprise-wide project control environment? It sounded wonderful and the team was inspired. Now the search was on for multi-project, enterprise-wide systems which could integrate the work of thousands of employees and hundreds of supervisors, project schedulers and managers.

It sounds wonderful, but there was a small fly in the ointment. The majority of end-users are already using desktop project scheduling software from a funny little company based in Redmond, WA. While very popular among end users, this software was deemed insufficient for managing the centralized, cross-enterprise needs of the firm. “Did the committee,” I asked, “have the mandate to replace this software across the board?” “Well… no.” was the answer. But, some committee members thought it was such a good idea that they were determined to lobby for the notion. It sounded like fighting the good fight but without the backing of the highest levels of management, this committee was destined for failure. Trying to replace the desktop product would ultimately be so contentious, raise so many issues and concerns, step on so many toes that the committee would be handcuffed in implementing anything.

At the telecommunications firm, the news was similar. Here, one division has successfully implemented a project management system across their entire group and have come to the conclusion that if only the other 30,000 employees of this firm would see things they way the 1,000 of them do, everyone’s life would be easier. Nice plan, tough execution. This firm, like most high-tech telecommunications firms these days is enjoying explosive growth and changing directions and goals faster than can be imagined. The only way these firms survive is to compartmentalize their operations, leaving each group somewhat autonomous with significant discretionary power. The individual groups agree on virtually nothing. It is, in some ways a problem but it comes with the territory. Implementing an enterprise system that could only be used successfully if everyone agreed on how it would be used, how data would be analyzed, what quality of data would be included and last, but not least that all … every bit of data would be entered into this particular system is going to be very difficult. The original idea was valiant but in this case, even if the CEO himself thinks it’s a good idea, deploying such a system is going to be tremendously difficult if it’s even possible. This presumes of course that the product(s) that are selected and that they attempt to implement can even carry the load across such a large number of users with so many diverse interests.

In the case of the financial company, reason has somehow prevailed. Here, the original notions of an enterprise-wide planning system have been toned down. Technicolor plans of real-time resource management with instant management oversight have resolved to a more modest first phase approach. This firm has elected to implement only one of a wide range of elements that may one day make up the final solution. In this case, the first element is an activity-based timekeeping system which will, of course, touch every employee in the firm, yet is already somewhat culturally accepted. This first phase, will deliver some of the results management has been looking for with an ability to closely approximate some others without having to deploy tools or collect data from every user.

The lessons seem to stay the same. If you are contemplating implementing an enterprise-wide solution consider some of the following elements:

Ø Do you have the authority to do so? Has someone high enough up in management; someone with the authority to impose this solution if need be, requested that this solution be selected and implemented and; do they understand what kind of commitment will be required of them if the plan moves forward?

Ø Is there a need? If end-users are already satisfied with whatever solution they may be using at the moment, how will you convince them to switch? What benefits will this solution provide to each level of the enterprise?

Ø Finally, consider a phased-in approach. After all, if it’s all or nothing, then you’ll need to wait until the entire system is selected, installed, configured, loaded with existing data, tested, people trained etc until the first byte of useful return will come out. This may take months years or… forever. A phased-in approach lets you get small victories with benefits along the way. It’s true that the final dream system may stay forever outside your grasp this way but… was it ever really within your reach anyway?

I suppose it shouldn’t surprise me. After all, it’s been 25 years and the request is almost identical each time. Again this week a very senior project manager asked for it again. “It” is a real-time, integrated project management system. The request came in a round-about way while I was demonstrating software for enterprise-wide use in a project environment so I had to double check. “Let me just be sure that I understand what you’re asking for,” I asked. “You’d like an enterprise-wide, web-based project management system that would manage its data in real time. In such a system the CEO for example, could click on a button and see a view of where all project stand at this moment. If they were to return in a few hours, the view would now represent all the changes that had occurred in the intervening time.”

The project manager’s eyes lit up. “You understand completely,” he said.

It fell to me to give him the bad news. “Such a system is demonstrable,” I said, “but could never be implemented.”

He was crushed. Who can blame him frankly? I remember standing in the exhibit hall of the annual Project Management Institute Symposium with the senior executives of two of the largest and long-standing project management software vendors. We were shaking our heads as we looked over the exhibit floor. Every booth it seemed was offering the same thing: “Enterprise-wide web-based project management”.

With all the promises from all these vendors of project management tools that offer this type of solution, surely at least one of them has figured out how to actually deliver it.

The problem is, that it’s not a technical problem. You see, as desirable as such a real-time report seems at first blush, it’s virtually impossible to deliver. The first issue is the context of the data you’re looking at. If I present a report of the status of a project, there are some basic assumptions that people make about the report. You assume, for example, that the data is accurate to the best of my abilities. To be accurate, project management data needs to go through at least some kind of review. You also assume that you’re looking at apples and apples, not a mix of different kinds of data. For example, if I show a report with 10 projects summarized on it, you would reasonably assume that the projects had all been statused on or around the same time. A report showing the status of some reports as of this week and others as of last month would be at best nonsensical and at worst could show a misleading view of our distribution and loads of resources.

This means that to create any such report prior to displaying it to management, I really need to update data on or around the same time and then validate that data through someone responsible for the project. This is the definition of batch processing. It is the very antithesis of real-time.

As soon as I point these kinds of issues out, it becomes obvious that there is going to be no easy solution to this request regardless of what the different booth displays say on the exhibit floor but there is another element of the issue that is almost never asked of the requestor.

Such requests typically originate from someone in the executive suite. A manager or director or senior executive of some kind asks why, with all the products on the market that promise such features, can’t he or she get the real-time analysis they’re asking for.

My first question of such people is “What will you do with it?” It seems trite I suppose but it’s really not. Imagine for a moment, such a system in place. Let’s imagine that through a petition to Harry Potter and his magic wand, we’ve managed to resolve all the issues with collecting, analyzing and validating our project data. Now, it’s 9:00am in the morning and our CEO is checking on the projects. He (or she) pops up the “corporate-wide-real-time-budget-vs-actual project report” Bad news. It shows the actual cost curve slightly higher than the budget curve. Our combined projects are over-budget. But wait! It’s 9:05 and the curve has just changed. Our budget curve has moved up, now the variance is alright. The CEO breaths a sigh of relief. Wait again! The curve has changed. It’s 9:15 and Bob, down in projects has just updated a half-dozen tasks with their new projected finish dates, now the curve is showing us over-budget again and we’re running late besides! But wait! The curve is undulating again. Even if this hapless manager were to take a snapshot and run down to the project department with it to ask how we’re going to get on track, the response is likely to be “Oh, you’re looking at the 10:23am report, you really need to look at 10:45, the picture’s all different.”

It’s obvious that such an environment would be completely unproductive yet the desire for it continues year after year unabated. This brings us back to the now dejected project manager who I met this week who wanted to know what he should do now? My recommendation was to change his question. Instead of searching for the real-time project management system, why not start asking what changes to his project management environment could he implement that would make them more effective. Not surprisingly, when he sets his sights a little lower, there is lots he can do.

It’s perhaps a good question for all of us.