One of the most common problems that organizations doing a big enterprise project management or enterprise timesheet deployment run into is trying to do more than one enterprise deployment at once. You would think that no one would deliberately put themselves into harm’s way by doing this but it happens often and that’s partly because of how insidious the problem is.

The road to trouble is paved with good intentions
Imagine if you will, being in a conference room in the very earliest days of an enterprise system deployment. The world is full of possibility. You’re working with management to identify key gaps in your organization’s processes. You’re looking at a myriad number of tools that promise to solve all evils. You’re narrowing down how you’ll attack the business challenges with the proposed system.

As you all look together at the processes that will be affected, it occurs to you that one of these processes reaches outside your original mandate. Perhaps you’re looking at creating a resource capacity planning system but it becomes clear as you design that solution that you’ll need to change the current time and attendance system. Or perhaps you’re creating a work management system and you realize that you really need to update the old CRM system. Or, perhaps you’re changing the way you do billing with a new ERP and you realize that you really need to update the document management system.

It’s the easiest thing in the world to let your mandate go beyond its borders and it’s the easiest while you’re in that honeymoon period of designing the new enterprise solution that you started with.

“Let’s just include that 2^nd system while we’re doing the first one,” says one well-wisher and now you’ve got not one but two enterprise systems to deploy.

Being pulled in two directions
Enterprise systems are change management projects. What that means is that they’re less about the particular functionality included and more about how they change business processes. By their very nature, enterprise system deployments reach deep into the operational behaviour of the organization and changes it to something that is hopefully more productive. Virtually any enterprise system can have this effect and the effect can be far reaching. A CRM system doesn’t just touch the sales people. It can also touch production, marketing, engineering, support and, of course, management.

With any enterprise system, we must go to senior management and ask what they wish to accomplish. My standard question for management is, “What business decisions can you not make now or can you make only with great difficulty, the making of which would be improved with this system?” That’s true for enterprise project management systems but it should also be true for virtually every system.

If you aren’t going to improve business decision making or operational efficiency in some manner, then there’s little point in deploying such systems.

But when we try to deploy two such systems simultaneously, we run the risk of pulling management in two directions at once. Even if the end result seems like a rational flow of decisions from Point A to Point B, the deployment of one of these systems will change behaviour and not just of management but of everyone the system touches. When we deploy a second system before the effects of the first stabilizes, not only will the second system be almost impossible to get established, the risk is to destabilize the first system as well.

The most common result is a complete failure of both systems.

Let’s take an easy example to see how this happens. An organization sees the need to improve efficiency in the area of project management. They decide to deploy a new enterprise project management (EPM) system to do so.

At the same time, the organization sees the need to improve resource management and decides that this can be done by deploying a new HR system, affecting all employees.

The two projects seem mutually exclusive and, indeed, for some time, the deployment teams might not even be aware of each other.

As the design of each of the enterprise systems evolves however, the changes driven by the design and deployment of the new systems start to run over each other.

The EPM system designers request a list of all departments, staff approval hierarchy and skills for populating the EPM system. These lists are delivered to EPM.

Over on the HR system deployment, a need has been revealed for better definition of departments staff hierarchical staff management and skill definition. The departments are realigned and redefined.

The HR changes are revealed to the EPM team who have already moved forward on their structure reworks the area that is affected by the changes in HR.

HR is informed by the EPM team that they will be implementing a resource management calendar for EPM and will require all vacation definitions updated weekly. They also send a list of new skills to augment the existing skill set.

HR has already redesigned the skill set for employees and the new definitions by EPM don’t fit. They begin to re-re-design the skills area of the new HR system.

And so it begins.

The most likely outcome is that a certain level of frustration will be reached and the original notion of integrating the EPM and HR data at the points it touches will be abandoned. Each team will go its own way. This might reduce or eliminate a key element of the expected benefits of the new system.

A less common but usually more damaging outcome is that as the frustration of the back and forth changes increases, someone in management figures that this could be resolved by putting both initiatives into one monstrously big initiative and working the projects together. This is rarely successful.

Moving from in parallel to in sequence
For most business initiatives, working multiple tasks in parallel is highly efficient. Deploying multiple enterprise systems is not in that category. When it becomes clear that there are two enterprise system initiatives that can touch each other, the most prudent action is to advance one of them and slow down the other.

Determining which enterprise deployment should go first will not be a popular task. It does, however, offer a great opportunity for benefit because this type of decision can really only be made by senior management.

One of the leading causes of enterprise system deployment failure is the absence of management involvement. Technical and operational personnel are often given deployment projects without direct involvement from senior management to determine what benefits are expected from those systems. When two such projects get underway at once, it’s a good moment to re-involve management in the process to identify what is expected by the organization from each system so that a decision can be made as to which one should be done first.

Some of the decision making criteria for deciding which system should go first might include: expected benefits, costs, return on investment, speed to deploy, severity of impact on existing processes and risk.

Only once the first project is in production and is stable should the second project’s design restart. A stable, in-production system is one where the organization has fully adopted its use, has changed its processes to adapt to the new environment and where the benefits of that system are already being realized.

In the meantime, if your project is the one that has been slowed down, all is not lost. Knowing that you won’t be able to count on a shiny new enterprise system to solve your problems sends you back to the drawing board to think of how to solve your problems without it. We’ve seen countless examples of where an organization realizes other ways to improve their processes while waiting for the new enterprise system deployment to restart.

Whether your enterprise project is going first or going second, it’ll be better than having it go together. Doing two enterprise projects at once is a worst case scenario.

I was working with a large Canadian company recently, helping with their enterprise project management processes. As part of my work, I got to watch while a project control officer prepared a report for the Chief Financial Officer.

It was a work of art.

First data was grouped together from multiple projects in the desktop version of a popular project management system. That data was copied and then pasted into a massive Excel spreadsheet as core data for what would become this report.

Now, this person grouped the Excel data and sub-totalled it. Next, a series of macros that were clearly cleverer than I am, created an entirely new Excel workbook with the data now grouped and sub-totalled in a completely different way. The project staffer now reviewed several thousand lines by eye, looking for discrepancies. When they found them, they returned to the first Excel cut-and-paste file and deleted lines, added lines and changed values so that the resulting final spreadsheet would be grouped in the manner they requested. When data really didn’t seem to make sense, it was removed for ‘later analysis’. The über-macro was run several times until finally the results were to this person’s satisfaction and then a second tab in the newly created Excel sheet displayed the data with lovely coloured headings and columns.

I was visibly impressed. But not in a good way.

During a report I made much later, one of the comments I made to the senior PM management was, “This report has a 100% chance of errors each month yet even though everyone knows how it is being produced, it is being interacted with as though it is financial quality data at the same level of quality as your payroll or your financial statements. You are making critical business decisions with this report that you know is flawed.”

The company took steps to improve their reporting process and created checks and balances to make sure the decisions they made were done based on information that they had a higher level of confidence in but the whole experience made me think about a deeper lesson that we can all take home. I wondered if there wasn’t incentive in the organization for this person to become the ‘indispensable project manager’; the person who is absolutely essential because they’re the only ones who can create the organization’s critical project reports.

We all have methods and processes in our project management environments that we’ve created ourselves and that can really only be accomplished by ourselves. If in this company, the person in question had to take a leave of absence, no one else on the planet would have been able to generate the report they did. That’s a risk factor for the PMO and it makes me wonder how many more such risk factors do we all have in our organizations.

The top level of virtually every Project Management Maturity (PMM) Model is to have the process be self-sustaining and self-correcting. Different models use different terms but the idea is the same. The original Capability Maturity Model developed by Carnegie Mellon University used the term “Sustained” for their top level 5 definition. This level of maturity indicates that the project management process can sustain itself and adapt or improve as changes occur. This would include, of course, changes in personnel which is always a risk factor to a process.

If the process was sustainable, then the steps to create a report, a method to test the report for accuracy and a schedule of when and how the report would be created would all be present. Hopefully this would be part of a much more extensive project management process guide that would include not just how to create a report but also the methods by which the data was collected so that we’d know the source information had quality as well. We often make important business decisions based on project data and there is often an assumption that the data is accurate because of how nicely it’s displayed yet it’s common to find project environments where data does not have verification for accuracy and where this is a poorly documented process.

I’ve been a big fan of a phased approach to things for a very long time so it’s a bit of a problem to me to find that the top level of the PMM process is often the last one tackled. I far prefer making an element of the project management process stable and then bringing that element all the way to the sustained level. Document the process, train the staff, repeat the steps required over and over, produce value from this one step and etch a groove for this one part of the process deep enough that it becomes ingrained in the corporate culture. Then build on the same method on the next element.

There’s a plus and minus to my thinking of course. On the plus side, the project elements I work on this way typically last a very long time. On the minus side, organizations rarely get to all the elements they originally envisaged. There comes a point where sufficient value is being produced by the elements of the project process that have been successfully adopted thus far that the incentive for additional investment is reduced.

From my perspective working on organizational project management, the pluses far outweigh the minuses. The bonus from the phased approach is that the process has power rather than an individual personality. There is no hidden, secret knowledge. The whole objective of a publicly known process is that everyone knows how the process works from start to finish. It’s all documented and all on the table.

Virtually anyone can make this kind of difference in their own project organization; small or large. Start by giving knowledge away by documenting how you get things done. If you’re in charge of a PMO, you can encourage team members to share their best practices and make them available to others but you don’t need to be in charge of the PMO in order to do this. It may seem counterintuitive to share your best techniques but don’t worry. Expertise isn’t a depleteable resource. You can generate new expertise tomorrow. Giving your expertise away and working to create your successful project management element as a sustainable part of your organization will have you leave a legacy; some difference that can last long after you’re not longer in that role.

After all, aren’t project managers about having others be more effective? That’s a real indispensable project manager.

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

Article: Collaborative Project Management – How to start collaborating
If you’ve already decided that collaboration will be a significant element of your project management environment, here is an article that talks about how get started with your collaboration efforts.

Article: The Dash for Dashboards
Dashboard views are all the rage within the executive suite.  There is a notion, fed in large part by software vendors, that executives can get real time levers and dials like they would while driving down the freeway so they can make instant decisions.  While creating dashboard views is quite easy now compared to several years ago, there’re more to creating such displays than just picking out the graphics.