The Resource Management Challenge

By: Chris Vandersluis
I originally wrote a version of this article for Microsoft TechNet. This updated version was written for the EPMGuidance site.

Resource management is the most popular reason organizations will switch from individual project management to enterprise project management so you’d think that would mean we’d have an extensive playbook on how to get the very best resource management out of such systems.

If only.

Defining Resource Management

The first problem, like so many aspects of enterprise systems is defining exactly what people mean by “resource management”. Depending on your perspective, resource management could be a number of different things.

Resource Leveling

Let’s start with the purist view. This comes from those of us in the industry for more than 15 years or so. When project management software was first made available as a commercial product, it was a critical path methodology (CPM) scheduling tool. There was no consideration of resources at all in those early systems. It was exciting enough to get a schedule out of the system and then when roll-feed plotters came out (mostly to support the technical drawing industry) to use them to get bar chart or logic (network) diagram displays of our projects.

When resources were factored into these systems, they were to enhance the original calculations with the addition of resources. The algorithms varied but the intent was to ensure that any delays from insufficient numbers of certain trades were identified long enough in advance to hire those people and get them on the job. We’ll come back to resource leveling a little later

Critical Chain Planning

It’s actually been around a long time although I know for some people the concept of Critical Chain seems new and is very exciting. For those who are schedule-centric, Critical Chain applies the resource constraints right into the schedule and looks for the resource(s) which will have the most profound effect on the schedule’s delivery. It is, perhaps, what CPM should have been from the beginning and when it’s applied in the right situation, it can be very revealing.

Resource Capacity Planning

If we expand our thinking a bit, we can include those first two definitions in a broader concept of managing the capacity of our resources. This is, by far, the most popular concept that we are asked to deliver on in an enterprise project management deployment. Resource Capacity Planning seeks to answer several questions for an organization’s decision makers:

Can I meet the commitments I’ve already made with the personnel I have?
- If not, what changes in personnel would be required to meet my commitments?
- If so, what excess capacity do I have to take on additional commitments?
- If I’m given an additional project, can I accomplish it with my existing personnel?
- If I cannot change my personnel, what will be the impact of new work I’m required to accomplish?

Resource Capacity Planning includes several concepts that must be implemented as part of your project management processes. These include:

Resource Loading
To start the Resource Capacity Planning challenge, we can start with how much work needs to be done. (If there’s no work to be done, there’s no need to manage the resources.) Having an accurate picture of how much work each task will take and who needs to accomplish it is critical to an accurate analysis.

Skill Scheduling
In modern project management tools, we can manage the resource requirement now just as a department or an individual but also as skills. Skill scheduling includes managing the resource requirement but also managing the skills availability as an inventory which seems to be more effective overall than just managing the number of people available in each department. After all, you might have a database management department but if the skills of your database personnel are lacking and that is the skill needed for the next project, then you’re skill lacking when it comes to getting the project done.

Resource Allocation
Who puts what resources onto the assignments? There is a process to be created to determine how resource requirements are defined and then resolved. Should you start by requesting a category or competency of resource? Should you make requests of individual resources in ‘Proposed’ mode and then have someone in authority make them ‘Committed’? Should you have different projects with proposed resources which are kept separate? Should a project manager be able to commit resources from different departments or should department heads have that privilege?

Resource Availability
You have the needs of the projects’ for resources but what resources are available? Who decides how much time each resource will make available for project vs. non-project work? Who decides when vacations can be taken? How will you determine how many hours of overtime can be worked a day? How will you deal with unpaid overtime? Will it become banked time?

Resource Leveling
Once you have both the availability and the needs of the resources for your projects, comparing the two should let you know where you’re over-allocated and present the challenge of dealing with the over-allocation. Should projects be prioritized so some get the resources and some don’t? Should some tasks be prioritized so some get the resources and some don’t? Should you use automated resource leveling? How about manual movement of tasks? Who will deal with reconciling a conflict where some parts of the company are waiting for work from other parts?

Resource Contracts
This term is typically found in a matrix organization where we have department heads who manage groups of resources and project managers who manage work that must be accomplished by those resources. Resource Contracts refer to the negotiation between the project managers and those department heads to commit resources to certain work. This might start as a request from the project manager for a certain person to be available at a certain date for a certain time. The department head might reply with a counter offer with an option of a different person with similar skills or the person requested by on a different date. The project manager then replies with an acceptance or a counter-counter offer and so on until the resource requirement is fulfilled.

Resource Tracking
For some organizations, the most important aspect of resource management is not the planning, it’s determining what has actually happened. “If you could just tell me what my people are actually doing with their time we’d be much more efficient,” a senior executive might ask. For these organizations, the timesheet aspect of an enterprise project management system becomes the most significant. Even without the integration back to the project plan, the by-activity accounting still gives an enormous richness of data to management of what each task cost in terms of effort and an interesting picture of how much time is available for project work and, more interestingly, what time is being spent on aside from project work. When we can tie the timesheet collection back to the project plan, then resource management can extend to budget vs. actual analysis. We can see what time was required for each planned task, the progress on that task so far and the impact of the progress on the projected finish of that task and any other tasks which may be affected by it.

Resource Communications
In a mega-project construction world, we used to not worry so much about resource communications. Foremen would pick up the latest news from the project office in the morning and tell their crews what they needed to know as they got started. In white-collar high-tech types of project environments, that’s not the case at all. A project team may now be made up of all kinds of people. Aside from the project schedulers and the resources who will do work, you might have executive sponsors, the users, the client, sub-contractors, out-sourced developers and more. It’s not at all uncommon to now have a project team which exceeds not just the walls of your office but also the boundaries of your organization. Communications in such an environment become much more significant. Resource Management in this context might be just being able to effectively collaborate with all the resources implicated in our project management process.

Resource Commitments
When we talk about project management systems, we tend to talk about a very algorithmic environment but managing the commitments of resources within a project is also an important aspect of getting things done. Project team leaders need to manage the commitments they’ve requested and the commitments they’ve made. A resource might say “I’ll finish that by Friday.” That’s a commitment; a promise. It might be a perfect match for the expected finish date in our schedule and it might not. It’s a commitment and that’s distinct from when the scheduling algorithm says the work should be done. Resource commitments might be managed in Outlook or SharePoint or on a white board or in some other commitment tool but they must be managed somehow.

Resource Sub-Contracting
For some organizations, just managing the resources that are contracted from other companies is resource management enough. When sub-contracts are involved, managing the promises the sub-contractor makes and ensuring that the contract provides the right incentive and is honored by the sub-contractor can make or break a project.

It sounds pretty straight forward. After all, the tools to manage all these aspects of resource management are readily available. Resource leveling, resource allocation, resource loading, skill scheduling are all referred to in the basic functionality of most scheduling tools Multi-project resource allocation is also commonly available functionality.. Resource tracking can be done with your timesheet system. Resource Contracts can be managed in forms/workflow tools or document management. Even Resource Sub-Contracting could be addressed with functionality from almost any collaboration tool.

The Challenge

You may note that I’ve not talked about Resource Capacity Planning and it’s not because it’s not possible. This is typically the most requested aspect of an EPM deployment but it’s one of the hardest to actually deliver.

There’s a fundamental challenge when we try to apply a resource leveling algorithm to a highly skilled group of resources. In order to understand it, it’s worthwhile to go back to what original designers were thinking when resource leveling algorithms were created. I promised to come back to resource leveling and even critical chain analysis and this is why.

When we think of the original resource leveling engines, they were designed for an engineering context. The first project scheduling tools were written for heavy engineering and construction projects where calculations would be done on one project at a time. Indeed, the entire organization might have been created to deliver a single project. Original commercial tools targeted the Defense and Oil and Gas industries which could take advantage of the heavy volume of data these tools could manage. But, when we look at resources on such projects, we always think of generic resources. Resource scheduling on such a project is inevitably done by skill. A project scheduler thinks of how many Mechanical Engineers, Electricians and Pipefitters they might need. Resource Leveling algorithms are perfect for this question. We have a number of resources, we level the tasks and the numbers of fulltime staff can vary upwards or downwards as need be. When we think of this for a significant number of the same type of interchangeable resource, the algorithm works rather well.

Modern project management has extended the concepts originally created for mega projects with large numbers of interchangeable resources and applied them all the way down to the individual level. The algorithm still seems to work at least in theory and it sure works just fine in a demonstration because we only ever show one resource at a time.

Let’s take this example:

I’ve created a very simple project here using Microsoft Project. Now, before you think that this is a Microsoft Project issue, it’s not. The same example would occur in any modern project scheduling tool.
You can see by the image here that I’ve started the project with a milestone and added two tasks which are to start right after the milestone is complete. As soon as I assign Chris to both tasks, I’ve got a resource leveling problem. As you can see by the split screen, Chris is allocated to twice his availability which makes perfect sense.

Now let’s level the project using the Resource Leveling algorithm:

Again, things appear perfect. As we’d expect, Chris’s tasks have been spread over a two week period instead of one showing how one of the tasks has to be delayed to a second week in order to get it all accomplished. Also, Chris is shown to be working continuously from week one to week two.

All is well it until we add another resource to the calculation. Let’s go back to our first situation and add a couple of additional tasks to the project but assign them to someone else:

Now I’ve got two people working at once. Chris is back to his over-allocated situation (you can see both of his tasks in week one and we’ve added three tasks for John who will start at the same time. John’s tasks though are already resource leveled because there is some sequence to them. If we’re looking just at John’s situation, it looks fine. John is working continuously from week one into week two but what happens when we apply the resource leveling algorithm now?

The resource leveling algorithm levels Chris’s time just the way it did the first time and Chris’s work is continuous from week one to week two. John however is going to have a full week’s gap in his work as he waits for Chris to complete his second task. It’s unlikely that we’ll want to have John reading the newspaper and staying idle in his cubicle for an entire week so it will now be up to John and Chris’s supervisor(s) to manually manage how they should schedule their time.

We’re only looking at the simplest example of two resources. The challenge becomes that much worse when we have a full team to talk about, more than one project that’s affected or more than one person put on each task.

This isn’t a software fault . This is just how resource leveling works with virtually every scheduling tool on the market. First the critical path is calculated then the resource constraints are applied to the schedule based on the options chosen. Different systems will have different options but when we apply a resource leveling algorithm to individuals, this is where we always end up. Modern project schedulers have learned not to apply classic resource leveling when scheduling must be done to the individual level.

This is also one of the fundamental reasons why we have to use extreme caution before having analytical scheduling tools like Project or Primavera or Open Plan push information into a Resource Commitment system like Outlook.

Outlook at its core could be considered a personal commitment system. You make commitments in your Outlook every day. For example you promise someone you’ll be at an appointment next week at 2pm. (that someone might be yourself). You promise someone you’ll complete a task by this Tuesday. We look at our Outlook today to see what tasks and appointments we need to fulfill and then use the communications functionality of the system to respond to others about the commitments we’re making or requesting. Imagine that we would now integrate that with our project scheduling system which is at its core, an analytical system. Moving activities from the scheduling took into Outlook and retrieving the progress on them is one thing. But, what if all of someone’s Outlook tasks would be integrated back into the schedule. I might make an appointment next week to be at the dentist for the morning. Should I now let the impact of this 4 hour gap in my availability ripple through every task I have scheduled in the future? Should all tasks be pushed 4 hours later? What about all the schedules of all the people I interact with or whose tasks are affected by my four hour delay? Should the entire company now start receiving emails saying their schedule has been pushed 4 hours later? But wait, I’m only one person. What happens when everyone’s Outlook commitments are affecting every task from every person in the company? In short order we have chaos.

If we are to integrate a resource commitment or resource communication tool like Outlook with a resource capacity planning tool, we need to reconcile the philosophical differences between the two paradigms.

Creating a Resource Management System

If you’ve made it this far, then you may be hoping I’ve got some advice on how to create resource management and I do have a few suggestions.

First of all, it’s worthwhile to talk about what aspects of resource management apply to your organization and which you can take advantage of quickly? It’s quite common to find that some aspects of resource management will be a bigger challenge to implement than others. I’m always keen to grab the low-hanging fruit first. You might be most interested in Resource Capacity Planning, for example but find that creating such a process and gathering all the data to create a consistent process is a daunting challenge. Yet, you might find that you can implement Resource Tracking with a timesheet system gives you less cultural hurdles to overcome. So, start with broadening your perspective of what Resource Management is to consider some other aspects.

If you’re looking at Resource Capacity Planning, then you have to appreciate that any resource leveling algorithm is going to have difficulties with resource definitions at the individual level. If that’s so, then you can think about doing resource leveling to the skill or generic level and leaving individual assignments to team leaders. This is often an area of an EPM deployment that is upsetting to senior executives. For anyone who hasn’t considered all the implications, it isn’t uncommon to imagine a system where analysis is done somewhere centrally and it not only magically reconciles every individual’s day-to-day calendar with their personal and corporate commitments but also ensures that they are working a full workday every day.

If Resource Capacity Planning is your concern, I’ve got an idea for you that’s not suggested very often. In any high-tech organization, skill scheduling to the individual level is very common because many people have a unique collection of skills and knowledge that makes them particular appropriate for certain kinds of work. If that is your situation, then consider creating a ‘Key Resource Project’. In my experience, the key resources in an organization represent less than 5% of the total number of resources. These key resources are the people that are essential to every project. They have that combination of skills and knowledge that is unfindable elsewhere and successful project managers know to make sure to get one of those key resources onto their projects if they want to succeed. A Key Resource Project would be a list of all of the tasks assigned only to those people. You would resource level their work and let all the other resources around them be scheduled however they are by team leaders. This can be implemented almost instantly and takes a relatively small amount of effort. Organizations who have tried this find it often resolves much of the heartache of resource leveling without the cultural challenge and process improvement challenges of a process that must include everyone.

It’s also worthwhile to think of your solution as being more extensive than just a single selection of scheduling software. When you consider all the different aspects of Resource Management, then you have to extend your thinking to your collaboration, document management, workflow, forms management, timesheet and reporting tools. These all can become vectors that are essential to creating an environment that is tailored to what you need for your organization.

GPS Assistance in Roadmapping an EPM Deployment

How do you create a roadmap for an EPM implementation?

Note: This article was originally published in Microsoft’s TechNet in 2008.

In a recent article, I talked about using a phased approach to making your plans for a deployment of an Enterprise Project Management (EPM) Solution. Today we’ll tackle making an EPM deployment roadmap as part of your project plan.

If you’ve used online maps or a GPS in your car you know that directions require two things: A destination and a point of origin. When we apply this analogy to an EPM deployment we have to think in similar terms:

1. Point of origin defined in technology, process and personnel terms

2. Destination defined in business terms and prioritized

We may also want to define some ‘way stations’ or interim stops where you can regroup, take pictures, enjoy the scenery for awhile and replenish your supplies for the next leg of the voyage.

When making a roadmap or directions, it’s pretty common to have two scales. We keep the next leg of the trip in great detail, down to a turn-by-turn route. We might also, however, keep a higher level map of the entire trip in less detail to keep our current leg in the context of the entire trip. In project management terms, we call this rolling-wave planning.

“Directions”

When making an EPM deployment roadmap, we always start with the vision or intention of where the company is heading in terms of its EPM efforts. This gives us the destination we’ll need to make directions just like an online map would.

If we were just to ask, “What do you want?” the answer almost invariably comes in terms of a solution. People are likely to say “I need a report that looks like this” or “Our firm needs portfolio analysis.”

For those of us in the solutions business, we know these kinds of design notes are fraught with risk. We train our consultants to be listening for clients who describe their problem as a solution. “That’s a solution to a problem,” we’ll say, “not the problem. Let’s define the problem.”

So we tend not to ask “What do you want?” Instead questions that may be useful during an envisioning might include:

“What business decision are you now unable to make or are able to make only with great difficulty, the making of which would be made easier as a result of this EPM Deployment?”

Or;

“What aspect of the organization do you believe could be made more efficient either through an increase in throughput or a decrease in effort through this EPM Deployment?”

Now, who should we be asking these questions of? Why, the people who make these decisions, of course! If you’ve ever had a minivan full of kids and turned to ask them where you should go as a destination, you know that you’ll get 50 answers.

By the same token, we need to make sure that the organization’s decision makers are a key part of this process or we run the risk of picking a direction that the ‘driver’ isn’t prepared to travel to. There’s an additional benefit to bringing senior management into the EPM roadmapping process at this time. Aside from being a critical participant in choosing the direction the EPM deployment should go, they are also able to get a sense of the magnitude of the project. One of the most common and difficult challenges to a successful EPM deployment is long term management support. Some senior executives have not considered just how much this might change existing practices and procedures and how disruptive, even temporarily, this might be. They may also not have an appreciation of how much effort a culture-change project like EPM may be.

During our work with senior management as well as project management and perhaps line personnel, we try to connect business decisions or business efficiency with process and technology. Is there a process that must be created in order to fulfill this requirement? What would it need to accomplish? Is there a system function that either exists or must be created to serve that business decision? What would it need to deliver?

Basic systems analysis is key in this phase. We start from the business decision ‘output’ and work our way back to the data elements required to make those decisions. In some cases, we find that the basic data simply isn’t there and this results in that element of the roadmap being flagged as ‘high risk’. After all, we’ll now need to include collecting data in a new format or structure to capture those new data elements before we can even think of delivering the better business process and that can be a tall order in some cases.

We have one more thing to do before we close off the destination process and that’s prioritizing the different elements of the final vision. It is very common to think at the beginning of the roadmapping process that the priorities will go one way but find that as you go to actually record them that they go very differently. Interestingly by the time everyone has agreed on what targets are included in our destination there is remarkable consensus on what the top priorities should be.

The next thing we need for directions is a point of origin and we manage that through an inventory of where the organization is now in relation to the goals we’ve chosen.

We look at existing personnel. Are they trained in project management for their particular roles? Do we have sufficient personnel with sufficient experience to accomplish the goals that have been set? Remember that we have to look a multiple measures here because different people will have a different role in the eventual enterprise project management process. It makes no sense to train every employee to be a project scheduler if, in fact, they’ll never be responsible to create schedules. By default, we think of 4 roles: Administrator, Project Manager, Individual Resource and Executive. If timesheets are involved, we think also of Supervisors as 5^th role. Of course, depending on what destination we’ve defined in our original envisioning process, the roles may be quite different. That changes the skills inventory process profoundly which is why we always start by defining the destination before thinking about the point of origin.

We also look at existing process. Is there a stated or documented project management process? How is it maintained? Who is in charge of it? If there is a Project Management Office already established then a lot of this effort is focused there. After all, there’s no point in creating new procedures if there are existing procedures and processes that are already effective. We’ve may inventory existing processes that are both inside the current project management process and outside depending on what the ultimate goals of the EPM environment will be.

For example, we may have decided that contract management is going to be a significant element of our new EPM environment and that this has never before been part of the project management processes within this organization. Yet, if we look a little further afield, we may find that the organization has a strong set of controls for managing documents and existing workflow already moving documents perhaps in SharePoint. This would be an ideal process for us to adopt and, if need be, adjust to make sure it will empower this aspect of the new enterprise project management environment. Doing so carries a triple-edged benefit. First, we don’t need to expend the effort creating a new process. Secondly, we know that the personnel already have the skills and habits to use the process in this way which means no training effort or effort to get the personnel to comply. Finally we don’t have the difficult situation of trying to create a separate process that might be at odds with an existing process for managing documents such as contracts.

We know that one of our biggest challenges is going to be compliance. Not building the system, but getting everyone to use it and to use it consistently. The more we can adopt existing habits, practices and procedures that are embedded in the organization, the easier compliance becomes.

Finally you need an inventory of the technology platform. Since each EPM Solution is built on a platform of technology, it is likely to find some of that technology already in place but it’s also possible the organization will have to upgrade some of its platform in order for the solution you’re designing to function. For example, SharePoint and SQL Server are obvious elements of deploying Microsoft’s Project Server but you may also need to check on browser compatibility (is everyone using the latest version of IE?), security status (will the system be outward facing?), what version of SQL is deployed (IS OLAP Services or SQL Reporting Services already being used?). You may also need to consider other systems to which you’ll need to interface or integrate. How will you get access to those systems in production.

The size of the planned system may also necessitate looking at hardware, network and other infrastructure elements to ensure the system will have the structure it requires when it arrives.

As with any enterprise system you’ll want to plan both a production and staging area so that updates and enhancements can be created in the lab rather than on the live system over time. You may also have to make plans for a Pilot or Proof of Concept phase; something I’ll talk more about in my next column.

“Recalculating Route”

When the GPS unit in my car discovers that I’ve missed a turn, a very nice lady’s voice says “Recalculating Route”. Moments later, the line through my map changes and I’ve got new directions. In an EPM deployment we need to be ready for a detour or a turn that’s blocked for repairs. Perhaps we missed that freeway exit. How do we deal with replanning? There are two things to ask when you go off course: First, are you still going to the same place? Second, how do we get there from here? One of my favorite project management quotes on this subject comes from Napoleon Bonaparte who once said, “A Battle Plan lasts until contact with the enemy.”

In an EPM deployment how do we apply this same principle? First of all, you need a measure to determine if you’re no longer on course. If one the team has an emergency dentist’s appointment tomorrow and is absent from the office for 4 hours should we then let that discrepancy change all downstream tasks, reschedule everyone from tomorrow at noon through the end of the project and then email everyone with their new assignment times?

Of course not.

A discrepancy of 4 hours for one resource over the 6 month lifetime of a project involving dozens of people isn’t enough of an interruption to warrant changing our path. What we need to do in starting any kind of enterprise project is to set thresholds of acceptable progress. The Aerospace and Defense world is finding a new term for this lately called “Tripwires” which is very descriptive. We can establish what criteria would indicate to us that our route needs to be recalculated. There are several typical metrics or measures to consider. First, if the projected completion cost varies by more than X percent from the original budget, that might constitute a project plan review. You might do the measure of cost in labor hours or money. Either is effective. Perhaps if the forecasted finish date varies by more than X days from the originally planned finish date that might constitute a project plan review. You might also identify missing certain key milestones by more than a certain number of days as a tripwire or you might identify certain risks being realized as a tripwire or you might determine that a change of certain key project team members such as the executive sponsor is a tripwire. It’s more important to set some criteria than to get the criteria exactly right. Also, remember you’re going to need to measure against these criteria throughout the lifetime of the project so if you choose 50 or 100 different metrics, you could end up spending more time measuring the project than doing the project!

Once you’ve determined you’re off course, the best place to get back on track is to conduct a project plan review. We recommend including representation from both the original group of senior management who helped establish our destination in the first place and from the group within the project management team who helped do the original inventory. Project Plan reviews can get mired down in assigning blame for why the project is off track and why a certain tripwire has been triggered. Such effort can be hugely counterproductive. We recommend focusing on the following questions:

1. What happened

2. Where have we ended up? What’s our current point of origin?

3. Are we still committed to our original destination or is there a compelling reason to review that process or even redo the Envisioning process?

4. Do we need to reset any of our intermediate milestones or phases?

5. Do we need to change any of our project team?

6. Do we need to reset any of our tripwire metrics?

Questions which we’ve found to be less productive include:

1. Whose fault is it that we’re here? Who’s responsible? Who’s to blame?

2. How do we get “back” on track; back to the old plan?

The most common reason for a project plan review is that the organization’s priorities shift. For example, items that were designed to be in Phase 3 are being demanded in Phase 2. This is usually a sign of a healthy dynamic within the organization and the result of people starting to think seriously about the implications of the EPM System’s deployment.

Bad Weather

Before you set out on a long drive you probably check the weather channel (or weather.msn.com) to make sure no inclement weather will affect your voyage. Risks are a part of life. Remember, if there were no risks, there’d be no need for project managers! Planning for the most glaring risks is not a complicated process. Start at the beginning of the envisioning process and as you look at each of the elements of the destination you are designing ask the group what barriers to reaching this destination they can think of. In some cases the risks will be significant. It’s not uncommon for an organization to desire a particular result only to find that the raw data required to deliver that result has never been gathered and that there may be considerable resistance to the collecting of that data.

In one example we found an organization that wanted resource capacity planning. That was going to require a complete accounting of all of the resource availability of all project personnel and a complete accounting of all of the possible workloads that could be applied to those staff. When we asked if both of those were available, we were told that sure, they were available but only for 2/5^thsof the organization. When we then discovered that the 3/5^ths of the organization that the data was not available for weren’t even represented at the envisioning meeting, we said, “Let us guess. The problems you’re experiencing with resource capacity planning are in those 3 divisions.” Naturally they were and we had to identify enrolling the division leaders of those divisions as a separate phase of the project and very high risk.

As you move on to work with the project management and line personnel in the inventory process, ask during the interviews for any risks these personnel might be able to identify.

Once the risks have been identified, it’s important to organize them. If you’ve not done this before, the most basic information will be the most valuable. Include:

1. A short description of the risk

2. The area or phase of the project on which it may impact

3. The severity of the risk if the criteria is realized

Finally, one of the most important things you can do is to add some details on risk mitigation. Just thinking about a risk is a huge mitigating factor but while the EPM deployment is in its infancy, entering some notes on how you might deal with a particular risk during the project can be invaluable. It’s common for decisions to be made in haste in an emotional context when risks are realized. Having some notes that were thought out while cooler heads prevailed may be useful.

Let’s drive the car we’re building

Here’s a tip on making your roadmap that may pay huge dividends: Use your project management system to help make and manage your roadmap plan. It seems obvious perhaps, but it’s rare enough for organizations to do that we mention it here.

I had a senior manager once tell me that his project staff had asked him if he thought making a project schedule and project charter to deploy an EPM Solution wasn’t overkill. “If we built jet planes for a living, we wouldn’t fly them to work,” they said. “Are you kidding?” he replied. “If I could fly a jet plane to work, I’d do it every day!”

In fact, using your own project management for the EPM deployment team is a great idea.

With the absolute minimum of configuration you can be up and running with a small deployment team as the users within a couple of days. This is a great way for those users who will become your deployment champions to become familiar with the use and benefits of the system before it arrives at the desks of the bulk of the staff.

This deployment shouldn’t be your production environment. You’ll almost certainly be configuring that and customizing it to fulfill the vision of the original destination. You almost certainly won’t be working on things like multi-project scheduling or resource capacity planning or portfolio optimization in your EPM Deployment, but you’ll be able to deliver a system that can deliver great benefits. We’d recommend:

1. Do a rolling wave schedule as a published project.

A rolling wave schedule highlights the current phase in great detail and future phases as more of a summary. This lets the team members know what they need to be working on now and still lets them see the project in a larger context.

2. Managing the vision document and other documents online.

Manage your project documents in a place that all team members can get access. Why not put all your project documents here for the EPM Deployment project?

3. Put your milestone sign offs and ‘gates’ into a deliverables document

This is a simple task list that you can link into tasks in your schedule. It will give a very high end view of the project and is easy tool to use for threshold management to determine when you go “off course”.

4. Put change management into your project documentation

Change management is one of the great challenges of technology projects. As new suggestions for changes to the project arise, get them into the Issue area as a potential change to be managed. By adding some structure to this area you can get a list of high priority items and who is responsible for them at any time.

5. Put the project risks into the document system.

Aside from documents and issues, tracking project risks for the deployment should have visibility.

Are we there yet?

“Almost. We’ll be there soon.”

An EPM deployment can bring an organization to so many different places that there’s no way to simply publish the default schedule for everyone. But, a few minutes searching the Internet may provide you with lots of possible examples for different parts of the project. If I summarize the roadmap exercise above, you are likely to end up with a project that has a few obvious phases:

1. Roadmap exercise

a. Envisioning (Choose the destination)

b. Inventory of existing processes (Identify the point of origin)

c. Inventory of existing personnel (Identify the point of origin)

d. Inventory of technology (Identify the point of origin)

2. Deployment of EPM solution for EPM team

3. Phase 1

a. Design

b. Configuration, Customization, Documentation

c. Pilot

d. Training

e. Roll-out

f. Review of Phase 1 and adjust Phase 2 as required

4. Phase 2

5. Phase 3

6. Phase 4

7. Project wrap up

Applying a roadmap exercise to your EPM deployment can change the experience from chaotic to manageable very quickly. Just remember to pick your destination first, figure out your point of origin next and to draw the path between them.

Happy travelling!

Archive: December 31, 2013

The Resource Management Challenge

GPS Assistance in Roadmapping an EPM Deployment