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