The Bat phone
The title of this article refers to Commissioner Gordon's liberal use of the Batphone whenever the City of Gotham was in dire straits (from the 1970s "Batman" TV series).
This article is part of our "From the Trenches" collection. It relates the fictional "Batman" story to how, during an EPM implementation, we at some time might wish we had access to a Batphone when we are in trouble. It also discusses many ways to avoid getting into trouble during the implementation.
To download the Word version of this article, see The Batphone.
To see more articles, see "From the Trenches" white papers.
The Batphone
In 1966, the original Batman TV series came on the air. It lasted only 120 episodes but it changed a culture in ways that last to this day. In the world of Batman and Robin (played by Adam West and Burt Ward), there was a 'bat' solution to everything. No matter what the problem, Batman would have the solution. The Batmobile, Batboat, Batplane, and Batcave all had their place. And if you were someone who needed help, no matter how difficult, how could you reach Batman? Well, with the Batphone of course! Pick up the Batphone and help would be on the way.
Commissioner Gordon would turn to the Batphone when things where hopeless, which occurred of course every episode. It didn't matter how difficult the challenge, pick up the Batphone and in 22 minutes (plus time for commercials) the villain would be vanquished and Gotham City returned to peaceful status.
Every solution in the Batman world was made to look like a Bat. Handcuffs? Bat shaped. Utility belt? Bat logos. Grappling hook? Of course — looks like bat wings. To my surprise, looking back at images of the Batphone it looked upsettingly normal. A red phone with a dial (remember those?) I'm not sure why it had a dial. It only called one place: The Batcave, where salvation was at hand.
As nostalgic as it may be to think of phones with dials and the old episodes of Batman, it's really not the point of today's article. It's been 40 years since the Batphone was retired, but people make calls to EPM consultants every day hoping the Batphone will work for just one more call.
Their villains are varied. Some are technical; they need to upgrade from version x to version y. Some are architectural; they need to make their internal EPM system talk to users in the outside world. Some are cultural; the users refuse to use the system. And some are procedural; the process they're following doesn't seem to deliver the result they expected.
No matter what the challenge, the request for the consulting firm is the same: Can you fix it in 22 minutes?
It's a situation that a surprising number of EPM users get into — a situation where they urgently need assistance to get them out of a difficult situation. It's often an emergency and the solution is required by management yesterday. The people who make these calls (I get a couple each week) are not feeble-minded. They are highly intelligent, capable, accomplished managers.
There is no Batphone, of course. I wish there were. I'd use it for all kinds of personal challenges. And so the people making these calls are rarely satisfied with the answers they get. So, let's take a few moments and talk about how people end up in such a tight spot that they feel that need to pick up the red phone and how you can avoid being one of them.
Getting into trouble
First let's talk about how people get into trouble while doing an EPM implementation. There are a couple of common causes:
Underestimating the challenge This is, by far, the most common error in an EPM deployment. It's not to say that every deployment must be large and difficult. That's certainly not always the case. But, perhaps because of wishful thinking, it's incredibly common to underestimate what it will take to get the benefits from an EPM deployment. The first error in underestimating is picking the target. Some people pick the installation of the tool as a successful project. It's not, of course. Some people pick the first use of the tool or the first report that comes out of the tool as the target. That's not it, either. A resolution of whatever problem(s) the EPM tools were chosen for is where you need to target. That means that the culture has changed, the training is complete, the usage is in production, the tools are working, the data is there. Yes, that may be a big thing — but if you're one inch short of that goal, you've still got nothing. (Well, almost nothing, anyway.)
Making it a technical project For those of us in the technology business, we're most guilty of this and really, most of us know better. Yet, somehow, the temptation to believe that the availability of technology means the problem is resolved is hard to resist. So many organizations we visit say some variation of "but we installed Project Server, why are our personnel overloaded? As we've said for some time, making enterprise project management work is a combination of people, technology and process and a good deal of change management thrown in for good measure. That doesn't arrive automatically when the software DVD rolls through the door.
Not involving management This, too, happens very often. After all, the people who best understand the benefits of an enterprise project management system are most likely those who are struggling to analyze the vast amounts of data that come from an environment with many projects and many resources. Enterprise project management is most popular when an organization tries to reconcile a complex set of conflicting priorities and a myriad combination of skills and experience. You would think that management would naturally be involved in such a project but it's often not the case. The challenge of changing the corporate culture from a single project mentality to an enterprise project mentality is almost impossible to overcome without them and yet all too often management is bypassed due to a worry that they will be unable to appreciate what it will take to get an EPM deployment completed.
Making unrealistic schedules There is no one who wishes that an EPM deployment will take a long time. And it's common to hope that the project can be accomplished in days or a couple of weeks rather than the months that is most common. There is also a common challenge of not getting the resources for an "internal" project such as EPM as readily as a client-based or commercial project. For these and other reasons, it's common to make a project schedule with resource requirements that are woefully insufficient.
Not applying project management to the project management system If you've read anything I've written, the chances are you've seen this before. Project managers are susceptible to the "shoemaker whose children are barefoot" syndrome. The result is a common lack of a project charter, an approved budget, a tracked schedule, dedicated resources and all the other accoutrements for their own project that are common to all the other projects they manage.
What were they expecting?
Ok, that's how people so often get themselves in trouble. The benefits expected by management from the deployment of an EPM system usually come directly from business challenges. It's the promise of solving those challenges that bring management to approve the expenditures for software, hardware, infrastructure and possibly even services. The most common of these challenges may sound familiar:
Resources are overloaded It may not be clear what the resources are being spent on, but it's very common to find that resources are overloaded. A more complex problem is finding that some resources are overloaded and others are under-loaded, which often indicates a mismatch between skills and experience available vs. those required.
Critical projects are not being completed in a timely fashion It should be obvious that critical projects should finish when they're planned, but life seems to interrupt such plans. This may be due to conflicting resource requirements, choosing too many projects that require too many of the same skill, or just bad prioritization. Sometimes organizations will think it's a lack of skill of the project manager but in a multi-project, multi-department matrix environment, the more likely culprit is organizational in nature.
Projects are not being completed within budget What holds true for the schedule can equally apply to costs. In high-tech as well as many other industries, the most variable component of a project's cost is the amount of labor applied to it. Take a lot longer with the same people and you're adding costs to the project. A stunning number of white-collar projects still remain untracked. They're planned but the actual cost per project is not recorded.
Your competition is completing projects faster than you are In a competitive economy, being first to market can make the difference between survival and oblivion. So, for many organizations, making sure that your project management is at least as effective as your competitors is important.
There is no visibility into what a projects resources are spending their time on or no way to know how much time is being spent on each project Sometimes no answer is worse than a bad answer. If you're in senior management this is particularly true. If you know the results are bad, you can apply your skills and the resources at your disposal to the problem at hand. If you know something is wrong but can't tell what, you're handcuffed. There's no way to know where to try to fix something.
How do I keep out of trouble?
You don't want to ever get to a point where you feel you need the Batphone. So, what can you do with your EPM environment to ensure that you don't end up there?
Okay, everything we said in the first section is obvious:
Do a good estimate
Don't think EPM is just a technical project
Involve senior management from the very beginning
Make a realistic schedule and give it a reality check by comparing it to others in your industry
Make a project schedule and project charter, and do all the things you normally do with your other projects
What else can you do?
First of all, start the project with an appreciation that at some point in the future, you're going to want to use the Batphone. You are. Knowing that, one thing you can do is to budget for assistance that you have no current plan for. We recommend that our clients budget 10% to 20% of the project for "unallocated requirements". "What's that for?" we're always asked. "You'll tell us later," we always answer. It's common to not use all that money. But it's also incredibly common to use some of it. Having a skilled expert already allocated and budget for your project makes a huge difference later.
Start with the expectation that the plan and the people will change. My favorite project management quote is from Napoleon Bonaparte, who said, "A battle plan lasts until contact with the enemy." It's true of EPM plans, too. Given that an implementation is likely to last several months, the chance that some personnel will change in the plan is enormous. So, plan for redundancy.
EPM systems evolve. It's common these days in an enterprise application to think of the "total cost of ownership". I think we should include the total application lifecycle in our EPM project plans. Have you thought about what version of a tool you're about to implement? Did you think about what other tools it depends on? How about the regular update/upgrade of those tools? Did you do customizations? How about customized training? Did you think of how those things will migrate to a new version should you deploy one?
Plan for redundancy of your experts, also. If you have a single consultant working for you, what will happen in a few months as you move to a new phase of your implementation or introduce a new key member of your team? Will that consultant be available? (Consultants move from one project to the next so the answer is often, "no".) If you work with a consulting firm, have you talked about how they can preserve the work of their staff to have others replicate it, if necessary?
Put that in writing
One of the most common and easiest-to-fix challenges comes from poor documentation. It's the easiest element to short-change but the existence of such documentation can make the difference between going back to a written reference and looking around for the Batphone. It's also not enough to write a document and stuff it into a drawer somewhere. Documents should become part of an ongoing record and your EPM process might reference them as part of a regular review process. Here are some of the documents for an EPM environment that I think are most critical:
Business Case I don't know what it is about the original business case that makes it so unattractive, but it's the most common thing to lose track of and in many respects, it's the kernel of why you have an EPM environment in the first place. The business case notes what the expected organizational benefits are; what does the organization expect from the EPM system? When we get a Batphone call, one of the very first things we ask is, "What is the system expected to be delivering for you?" We don't just ask the administrator. We also ask management, the users, and the business beneficiaries. The most common answer is a different answer from each party. That's because the original business premise has become lost.
Roles and responsibilities In the last version of roles and responsibilities, we often resolve to an individual's name, and it doesn't take long before the role that individual plays in the EPM system is forgotten. Keeping a roles and responsibilities document will allow you to adjust the parameters of who does what in the EPM process as the organization naturally goes through personnel changes or even organizational structure changes.
Process Guide and Flowchart This is often forgotten when we get down to procedural guides. People are left with the "What-to-do" steps in a procedural manual but not the context for why those steps are important and what we do with the result of each step. A process guide and, best of all, a visual flowchart will let future managers understand what the system provides and make it much easier to adapt the system in the future.
System Selection Criteria When you choose your EPM system and any third party tools you may have selected along the way, let future generations know what your decision was based on. We've gone into organizations 5, 7, or even 10 years after a system was deployed and seen a system with several tools associated with it and asked "Why are you doing that? It would be much easier doing this!" The reasons for those decisions are nowhere to be found. In some cases the client has spent years doing something in an extremely complicated fashion that could have been so much easier given more current versions of existing tools. They can't make an easy decision to change a tool or use a more current version because they no longer have access to why they chose to do something a certain way years ago.
There really is no Batphone.
When I say that, it feels like I'm saying there really is no Easter Bunny or no Santa Claus. It's just bad news. But there really is no Batphone. I'm sure, though, that just the absence of that magical phone won't stop people from calling me tomorrow asking me to vanquish Gotham City's latest villain. If you get into trouble and feel the need to call an expert, here are a few recommendations:
Listen to the advice you get. It is silly to pay an expert to give you advice and then decide you know better than they do. If you're going to ask for advice and you're dealing with an expert, try to listen and at least consider the advice. Batman wouldn't have kept showing up for Commissioner Gordon time and time again if each time he did so, Gordon said, "Now that you're here, Batman, please do the same thing all my other policemen do."
Batman could do it in 22 minutes, but you probably won't. If you're calling an expert, let him tell you how long it should take to fix your challenge. You can elect not to fix it after he's done, but fixing EPM challenges, even technical ones, rarely takes only a few minutes. After all, Batman had to do it in 22 minutes because 8 minutes were allocated for commercials, and they are essential.
Commissioner Gordon never told Batman the solution, only the problem. All too often we get a call from a panicky EPM administrator who knows that I need to apply a patch, write a report, and train two people. I always listen to this patiently and then ask the client to describe the problem as they've just described to me the solution. Before you pick up the phone to call an expert, think first about what problem you'd like to lay on their table.
Conclusion
You really need to use the Batphone. Ask around. Don't ask just one consulting expert and don't get just one possible solution. Ask your colleagues or others in industry who they know who might take a Batphone call, and talk to at least two of them. It's a good reality check to see how one expert vs. another might deal with your problem. Remember, Batman may have been amazing, but there are many superheroes to choose from!
About the Author
Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.
Chris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca
If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (https://www.epmguidance.com/?page_id=39).