People

Technology

Strategy

EPM

Process

AUTHOR RICK KHOSLA

EPM ROADMAP

MICROSOFT PROJECT

Table of Contents

INTRODUCTION 6

WHAT IS ENTERPRISE PROJECT MANAGEMENT? 6

Basic Project Management 7

Enterprise Project Management 7

Project Portfolio Management (PPM) 7

Resource Management 7

Reporting Analysis 7

Budgeting and Cost management 7

Timesheets 7

Communication and Collaboration 8

Integration with External Applications 8

Workflow 8

Business Intelligence 8

THE PROJECT MANAGEMENT MATURITY MODEL 8

EPM DEPLOYMENT APPROACHES 9

Big Bang 9

The Instant Bang 10

The Phased Approach 11

GETTING STARTED WITH YOUR EPM DEPLOYMENT STRATEGY 12

1. The Project Management Office 12

2. Executive Sponsorship 13

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

4. Set goals 13

GETTING STARTED 13

Envision 13

Who’s who? 14

Make a Project Plan 14

CONCLUSION 14

DETERMINE PROJECT MANAGEMENT REQUIREMENTS (PROJECT SERVER 2010) 15

DIFFERENT STROKES FOR DIFFERENT FOLKS 28

FACTORS IN CHOOSING YOUR PROJECT RESOLUTION 31

How long is the project? 31

How many resources are involved? 32

How are resources managed or sub-divided? 32

How quickly can you gather data and how much effort does that take? 33

How often will we update? 34

REVIEWING YOUR WORK 34

Is it too much? 35

Should we do it at all? 35

A nimble… no, an Agile project 35

Wrapping up 36

WIZARD OF OZ SYNDROME 38

MEASURE EVERYTHING 38

HALF-BAKED PLANS 39

BEST BEFORE DATES 40

DATA PEDIGREE 41

ARE WE LOOKING AT THE WHOLE PICTURE? 42

GAMERS GALORE 43

Change the process 44

No carrot, just stick 44

Checks and balances 44

SOME BASIC RULES 44

Indicators must trace back to source data 44

Every indicator needs an action 44

The data must be complete or show that it’s not 44

The display must show its timeliness 44

Check data quality in an ongoing fashion 45

1 – Planning 52

2 – Tracking 52

3 – Resource Management 53

4 – Cost Management 53

5 – Advanced 53

CREATING AN EPM DEPLOYMENT PLAN 71

1. ESTABLISH THE EPM SYSTEM DEPLOYMENT TEAM 71

Identify Key Stakeholders 71

Identify internal expertise resources 71

Engage external expertise (if required) 72

2. IDENTIFY BUSINESS OBJECTIVES 72

Executive and Stakeholder workshops 72

Identify management role impact 73

Prioritize business objectives and create a Master Deployment Plan 73

Establish milestones and metrics 73

PHASE 1 73

3. INVENTORY PROCESSES 73

What processes exist and can be adopted? 74

What processes must be designed 74

Process whiteboard workshops 74

Resolve impacted management roles 74

4. ADOPT, ADAPT, AND DESIGN PROCESSES 74

Review, adapt, and accept designed processes 74

5. EVALUATE AND SELECT EPM TOOLS 75

Prepare “problem statement” documents for vendors 75

Solicit vendor responses 75

Short list 75

Vendor and implementer presentations 75

Tool selection and acquisition 75

6. AUTOMATION DESIGN AND CONFIGURE 76

Apply the process design document to the selected EPM tool 76

Design and implement standards 76

7. PILOT EPM TOOL 77

Phase 1 install / configure / migrate data 77

Training 77

Run active projects 77

Lessons learned and document 77

8. ROLL OUT PHASE 1 INTO PRODUCTION 77

Go-live 77

9. REVIEW AND ADAPT MASTER DEPLOYMENT PLAN 78

Review and adjust master plan in preparation for next phase 78

10. PHASE 2 – DO STEPS 3 THROUGH 9 AGAIN 78

Introduction

One of the biggest challenges we face when we start an EPM deployment is establishing a credible

roadmap for producing the intended result. While I have deployed enterprise project management

systems here for over 16 years, one thing that hasn’t changed is the desire of senior management to

have all the results yesterday.

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 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 or groups of projects, and analyze and report on them together. We’d need to

be able to track progress at this summarized 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, score carding 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 score carding, dash boarding 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

People

Technology

Strategy

EP

M

Process

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.

If we try to implement every aspect and every direction at the same time, we could end up creating a

huge project that is complex and very difficult to understand and that just makes the deployment much

riskier.

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

than 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 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 as 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 that 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. Having 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 the 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!

Determine project management requirements (Project Server 2010)

It is important to determine the project management needs and requirements for your organization. Your configuration will vary according to the kind of work that your organization performs and whether you use Project Server 2010 for time tracking, collaboration, or portfolio management. After you characterize the typical projects for your organization, determine which Project Server scenarios that you have to support.

Once you have completed determining your project management requirements, see Plan for performance and capacity (Project Server 2010) to determine the hardware requirements for your Project Server infrastructure.

Characterize your projects

Understanding the characteristics of the projects in your organization enables you to plan your Project Server 2010 configuration. The following characteristics have a significant effect on your configuration:

The number of projects that your organization is working on at a particular time. The size of your projects, which varies with the number of tasks and assignments that

your projects include. The length of time that is required to complete a project. The number of team members that are assigned tasks in projects.

Most organizations manage projects that vary in size and duration, but the degree to which they vary is a function of the size of the organization and the kind of work that it performs. For example, a large consulting company might manage several thousand projects that range from small, 10-task projects that last two weeks to large projects that include 1,500 tasks and last for over a year.

Organizations typically have many projects that range in size from small to medium to large. For planning, make sure that you can adequately support the kind of project that your organization works on most frequently.

Determine your Project Server 2010 scenario

Your project management needs and requirements vary according to the kind of work that your organization performs. As part of your configuration planning process, determine which scenario that you need to support. For example, you can use Project Server 2010 to support the following kinds of scenarios:

Enterprise Project Management Time tracking Demand management

Using Project Server 2010 for Enterprise Project Management

The Project Server 2010 scenario for EPM applies to a large organization whose area of focus is top-down planning driven through the Project Management Office (PMO). This scenario is more frequently seen in the product development and manufacturing markets. It has the following characteristics:

A small number of large projects that are often related Focus on the PMO Extensive use of Microsoft Project Professional 2010 Work Tracker usage

Critical considerations for this kind of deployment include the following:

The level of detail to track Using leveling as a process How to prioritize capacity How to use skill tracking

In this scenario, client usage is as follows:

Client application Rate of usage

Project Professional 2010 High

Project Web App High

In this scenario, server usage is as follows:

Project Web App feature Rate of usage

Work Tracker High

Programs High

Timesheets Medium

Portfolio management Medium

Master projects High

Project workspaces Low

Risk management Medium

Issues management High

Document management Medium

Resource management Medium

Task management Medium

Using Project Server 2010 for time tracking

The Project Server 2010 scenario for professional services/timesheet deployment can apply to a large organization that wants to use Project Server 2010 mainly to capture and report time. In this scenario, employees and contractors use Project Server 2010 timesheet functionality to submit hours worked on tasks during specific time periods. This scenario has the following characteristics:

Minimal use of Project Professional 2010 Time and material billing A large number of projects that have fairly few tasks A predictable peak period of usage that corresponds to scheduled timesheet entry in

Project Web App

Organizations that support this scenario typically use a limited set of Project Professional 2010 features to track time and costs by using timesheets to capture information. This scenario presents scalability issues, because, when many timesheets are submitted in a short period of time, system resources can become severely strained.

Critical considerations for this kind of deployment include the following:

What time classifications to use What time periods to use Calendars and overtime setup What fiscal periods to use Source of cost data Custom field configuration — process control custom fields vs. reporting custom fields Currency configuration Auditing

There are additional factors that can be affected by the processes that are used within your organization, including the following:

Types of usage What the project update cycle is What the reporting cycle is

In this scenario, client usage is as follows:

Client application Rate of usage

Project Professional 2010 Medium

Project Web App High

In this scenario, server usage is as follows:

Project Web App feature Rate of usage

Work Tracker High

Programs Low

Timesheets High

Portfolio management Low

Master projects Low

Project workspaces Low

Risk management Low

Issues management Low

Document management Low

Resource management High

Task management Medium

Using Project Server 2010 for Demand Management

The Project Server 2010 scenario for Demand Management deployment can apply to any medium-to-large organization that wants to use Project Server 2010 to manage project portfolios. These organizations typically have the following characteristics:

A large number of projects that have many assignments A high percentage of project managers Frequent use of Project Professional 2010

Organizations that support this scenario typically use the breadth of Project Server 2010 features that include timesheets, document libraries, issues, risks, the Enterprise Global Template, and the Enterprise Resource Pool.

The organization to which this scenario can apply can be as small as a medium-size organization (or a department in a larger organization) whose users all share the same physical location on the same LAN, or it can be a large organization whose users work in several different physical locations.

These organizations use Project Professional 2010 and Project Web App daily to publish or update projects to the Project Server 2010 database, and they use Project Web App to view assignments; report actuals; and access documents, issues, and risks. Additionally, these organizations generate online analytical processing (OLAP) cubes weekly.

Critical considerations for this kind of deployment include the following:

Level of resource data to track What project nomination process to use What kind of review process to use What the report cycle will be Workflow requirements What kind of work to track Who manages the process What demand is captured

In this scenario, client usage is as follows:

Client application Rate of usage

Project Professional 2010 Medium

Project Web App High

In this scenario, server usage is as follows:

Project Web App feature Rate of usage

Work Tracker Low

Timesheets Medium

Portfolio management High

Programs Low

Administrative projects Low

Collaboration Medium

Document management Medium

Risk management Medium

Issues management Medium

Resource management Medium

Project workspace sites Medium

Top-down or bottom-up?

“We need project management… Ummm, I meant portfolio management… Ummm, I really mean task

management… Oh heck, we need all of them,” is a battle cry I hear often. It’s not a lack of definitions of

these three concepts that causes confusion, it’s their similarity.

Those of us who have worked in IT for many years tend to see things from a technical perspective and

sometimes it doesn’t serve us well. If we look at data from Portfolio Management, Project

Management, and Task Management, it might look very similar. I’ve got an ID field, a description field,

and a start and end date in all three. Linking all three of these should be natural then.

Perhaps not.

Let’s take these three concepts one at a time. It’s easy to see their similarities, but there are

fundamental differences in the three perspectives.

Portfolio Management — a top-down approach

People can mean a lot of different things by “portfolio management,” but the most meaning common is

probably project selection and prioritization. The principles ultimately affect everyone in the

organization, but the process is of great

interest to senior executives.

Management starts off with certain

constraints, such as a total available

budget and a need to answer the

question, “What can we and should we

accomplish with this amount of

money?” If the portfolio management

process is sufficiently mature, this

analysis might include not just new

ideas but also existing projects.

To create a portfolio selection and

prioritization process, management

must confront what business criteria drive the company and agree in advance on the metrics that will be

considered when looking at new and existing projects. Should return on investment be a key metric?

Perhaps we should consider effects on client satisfaction or staff retention or alignment with strategic

objectives. Whatever the key metrics are, management has to weigh each project initiative with a view

to how that project can advance those objectives and how each project compares with alternate

initiatives on which the money could be spent.

This is a highly analytic process even if it’s done in one’s head. It’s certainly highly analytic when you are

using project portfolio management software. Even once the analysis from software arrives in a report

or a view, there is virtually always some management-level oversight where a final decision on priorities

gets made. When that is complete, the final results must be transmitted to those who will do project

management of each of the projects. The effects of these decisions will be to fund some projects and

not to fund others, to make available resources on a higher priority to some projects and not to others,

and to advance the schedule of some projects and to delay others.

Project Management — top-down and bottom-up

Once a project is approved, it moves into a different realm altogether. Now the more classic view of

project scheduling comes into focus. Now we have to actually build the thing we described in our

business justification before it was approved.

A project manager starts thinking in terms of project scope and deliverables. The project manager

knows the final product that must be

created, whether it is a piece of software or

a building ready for occupancy. They may

think of the major phases of that project

and create a work breakdown structure.

A critical path of logical steps required to

complete the project gets designed.

The project manager also knows that he or

she will be held to account for the schedule

that is produced, so he or she consults a

range of subject matter experts in the project. The project manager creates a bottom-up view of the

project by looking task by task and summarizing those tasks up to project phases and eventually to the

project itself. At this time the project manager might also start allocating resources by skill, by

department, or even by name. These

resources might have costs associated with

them. The result of calculating the duration

of the tasks, the resources required, and

their rates gives us a bottom-up estimate of

the project.

So far, so good.

But when we look at the top-down

approach of the project portfolio selection

process, there was a cost, too. In fact, the

estimated cost of the project was part of the business justification that management considered when it

approved the project. If we’re just getting the bottom-up estimate of the project from combined

expertise of the subject matter experts now, what did they use in the project selection up in the

executive suite?

It’s a good question. In some organizations, the project will be given a rough estimate from the project

department in order to create a business justification for the project. In other organizations, a complete

bottom-up estimate is created prior to considering the project in the portfolio process. The problem

with both of these approaches is that they take effort. A complete estimate may take a lot of effort and

yet the project has yet to receive approval for funding any effort. So, in many organizations, someone in

management simply makes a guess as to what the costs of this project will be.

So the process looks all integrated but there may be a bit of a catch-22 here. Which comes first, the

work spent on doing the estimate or the selection of the project in order to be able to spend time on the

project?

Moreover, what happens if the bottom-up estimate doesn’t match the estimate of the portfolio

selection process? If the estimate is less, there’s probably no issue, but if the work can’t possibly be

completed in the time or budget estimated by the portfolio selection people, there is a conflict.

You might think that the natural thing to do would be to reconvene senior management and just discuss

the problem, but there are a lot of situations where that isn’t as easy as it seems.

First of all, the portfolio selection committee is rarely the project management staff. Senior project

management staff members are almost always included in the portfolio selection committee, but the

group itself is usually very senior executives who find it challenging to organize time to all be together.

Secondly, the selection committee may meet irregularly, so getting them back together to discuss all the

ramifications of a mismatched cost for one project versus the estimate might be a big challenge. Finally,

there are some corporate cultures where it will not be a career-advancing move to have to deliver the

news to the senior executive that their guess is completely wrong on what the appropriate schedule and

budget for this project is.

Task management — a bottom-up approach

When we think of task management, we tend to think very operationally, and that most often brings us

to our daily agenda and a product like

Outlook.

Now we’re working at an individual or a

small team member level. We don’t see

the tasks in context. We see those things

we’ve committed to or perhaps those

things we’ve asked a team member to

commit to. This is not an analytic view at

all. There are tasks to do and the

individual has promised to do them.

At its core, task management is very straightforward. You do the task and when you’re done you tell the

person who gave you the task to do that it is complete. All the functionality for this is already in

Outlook.

The mischief of similar data

There’s a saying, “If it looks like a duck and quacks like a duck, it must be a duck.” That’s true for ducks,

but it isn’t always true for task-based data.

Let’s consider these three levels of project-oriented data:

At the portfolio level, we have a project and perhaps phases below that project. The phase information might have a code number, a description, a duration, a start date, and an end date.

At the project level, we have a project and tasks below the project. The task information might have a code number, a description, a duration, a start date, and an end date.

At that task management level, we have a task and the task information might have a code number, a description, a duration, a start date, and an end date.

They sure look the same, but in fact, the perspective of the data makes each of these rather common

records serve a very different purpose.

I’m often asked, “Can I move data from the portfolio view to the project view to Outlook and back.”

The short answer to that question is “Yes.”

But in our firm we have a mantra we say to ourselves when we’re giving technical advice: “Don’t tell me

how to do it, tell me why you should do it.”

1. To make the point, imagine this example. We make an entirely integrated environment. At the top end of the scale we have a list of projects organized by portfolio. Not only do we select these projects, but we integrate even further, following them after they’ve been activated into live projects from the EPM system. To do this, we use functionality already available to us to move the project and phase definitions from the Portfolio side of our integrated system to the project side of the system. The data looks identical.

2. In our enterprise project management system we now make a more detailed definition, using the original phases from the portfolio definition that was pushed from the top down. Doing this allows that summary to be updated in the portfolio system when we update our projects. We make many tasks and assign many resources. We now do a resource-leveling analysis to determine our capacity across many projects.

3. We use our resource assignments to push task and assignment data to each user as an Outlook task or calendar event. Users no longer need to go to a “project management system”. They are now able to see their data in their daily agenda. The data looks just like it does in the project list and is linked further upstream to the portfolio view.

4. Progress from these tasks and availability from Outlook is moved back from the individual to the project management system along with estimates on when this work will be completed. The data looks just like it does in the other two systems, so moving the data is relatively easy.

Creating such a system is technically very straightforward using the tools available to us today along

with a bit of configuration and development. And it would demonstrate beautifully.

We get asked for exactly this type of structure on a regular basis. But, even though we can do it, should

we?

Imagine that at the task level, an individual takes the morning off for an emergency dental visit and

updates her Outlook that she will not be available this morning. That’s bad news for him but the ripple

effects to the project could be massive. Now, the project system calculates that the task that was

scheduled to be done this morning won’t be completed today; it will be completed only at mid-day

tomorrow. It dutifully looks at the critical path and all tasks downstream from this one and pushes them

forward by four hours. Perhaps hundreds of tasks were affected. The result might be pushing the end

date of the project a half day later. Other projects are also affected as other people working on this

project must now have their tasks re-arranged and the portfolio view itself slides forward a few pixels.

If we imagine this in real time, the problem is magnified. Hundreds or thousands of people are making

changes all through the day, and the EPM view, the resource leveling view, and the portfolio view

animate back and forth with the effects.

In reality this doesn’t happen. First of all, the hapless dental patient will be back at her post at noon and

may just work a few hours later tonight to make sure this critical path is caught up and all will be back

on track in the morning.

Plus, even though the data looks the same, it is never integrated this way because of exactly this effect.

Data Context — the perspective matters

When we look at data, the context of the data is critical. Data that may look the same from a record-to-

record schema is used for very different purposes based on the perspective of the application.

In a top-down portfolio view, we are making strategic decisions of where to put our resources to

maximize our return on investment. We might make choices that a project manager wouldn’t make. In

my own organization, we have sometimes chosen projects that are completely outside our existing skill

set, knowing that we would be terribly ineffective at accomplishing them but doing so because we

wanted to improve those very skills. The return on investment wasn’t an effective installation, it was

trained installers. This is an analytic view.

In a tactical project view, we are making operational decisions about where to get the best throughput

of our personnel and to get our projects completed as quickly and efficiently as possible. A project

manager’s eye is always to the future. What happened in the past is only of interest to the project

manager insofar as it improves his or her view of the future. This is also a highly analytic view.

In a task management view like an agenda, we are not analytic. An agenda is a commitment system.

We promise ourselves or others that we will do a particular thing at a particular time. This might fit the

analytic view. And it might not.

Mixing these perspectives and contexts without understanding the impact can cause chaos.

Top-down or bottom-up?

There is, as usual, no right answer. Some aspects of your project management system really need to

come from the bottom-up. After all, in the end, it is individuals who will build whatever your project is

about. But some decisions are, and should be, made from the very top and are, as a necessity, top-

down.

When you keep the distinctions of what each level of the project management paradigm is for, it does

become clearer to see if some of these

systems should really be integrated or

not. If the process and thinking of one

level doesn’t have direct benefit by being

fully integrated from another level, then

integration is not the best play. It’s

important to walk through how such

integration would work in a real-world

context and whether the frequency and

detail from one level delivers any value to

the other.

If, for example, a steering committee only

meets once a quarter to make big-play

decisions about which projects to move forward and which not, then what is the benefit to updating

their view every day, every week, or even every month?

Does the enterprise project management resource-leveling algorithm really need to see the dental

appointment of an individual or is it enough to know the approximate availability of that individual?

And yet, if we could send an assignment to an individual’s agenda or timesheet screen directly, would

that save them a few minutes each day having to go into a different system and interface to see the

same data?

So, top-down is right in some circumstances and bottom-up is right in others. You have to look at your

own situation to see where integrating these tools and concepts can pay back the right dividends before

tying them together.

They say they want a resolution

With apologies to the Beatles for the title, today’s topic is the resolution of your project.

There are lots of materials available on how to make a schedule, but one of the most critical lessons is

awfully hard to come by—how many tasks you should have in your project schedule and how long each

task should be?

On a regular basis I’m confronted with project schedules that seem impossibly complex or with project

managers who seem helpless to pinpoint trouble in their schedule because the schedule is at such a

summary level. I’ve seen a project that was over a hundred years long (yes, really) that was perfectly

appropriate in length and in which there were some tasks that were decades long. I’ve also seen project

schedules that lasted only an hour or less that were perfectly appropriate and in which some tasks

lasted only a single minute. I’ve seen projects with only a handful of tasks and others with over 100,000

tasks.

The software we use today can handle thousands of tasks and a wide range of durations.

So, what’s the right approach?

How long should tasks be, and how many should we have to optimize our project schedule? I will call

this the resolution of the project.

Different strokes for different folks

Because the requirement might be different for different industries, different kinds of projects, and

different situations, let's look at how to decide how many tasks to put in your schedule and how long

tasks should be.

Different kinds of projects naturally call for different kinds of schedules. Let’s think about three

different examples:

1. Software development Many software projects have common characteristics. While every software project is unique, there is typically a design phase, a programming phase, a quality assurance phase, a document phase, and a deployment phase. Software projects are typically measured in weeks or months, and that lends itself to tasks that are a day to a couple of weeks long. Resource allocation here is often assigned to the individual level. Those who have embraced the Agile process for developing software look to short “sprints” of one or two weeks and within that sprint put tasks that are of brief duration, but the overall project duration is still measured in weeks. We’ll talk more about Agile development a bit later.

2. EPC – Engineering, Procurement, and Construction EPC projects are where the Critical Path Scheduling methodology got its start. In this kind of project, something very big is being developed. It could be a large defense project like the Polaris Missile project that gave PERT diagrams their start, or it could be an offshore oil rig, a new ship, or a power plant. In these kinds of projects there is an engineering phase where the finished project is conceived. The Engineering phase typically has some aspect that has never been designed before. The Procurement phase looks at locating, contracting for and managing the delivery of supplies or sub-contracts for elements of the project. In the Construction phase, the final product is constructed and then commissioned for use. We typically think of EPC project schedules in many months or several years with activity durations lasting anywhere from a couple of weeks to a couple of months. It’s not at all unusual to have 5,000 to 20,000 tasks on such a project. Resource scheduling here is almost always assigned to the skill level rather than the individual, and (just to add to the fun) there may be many sub-projects made into a program or master project for ease of management.

3. Plant shutdown When you do a project schedule for a plant shutdown and turnaround for maintenance you are working in one of the most challenging scheduling environments possible. A plant shutdown to do maintenance comes in two flavors: planned and emergency. Let’s leave the

emergency type aside for a moment; it’s a world unto itself. The duration of a planned plant shutdown is heavily dependent on the type of plant. A nuclear power plant unit, for example, might do a “fast” plant shutdown and turnaround in 12 months. An oil refinery might last 4-6 weeks. But the type of plant project schedule that I find most interesting is a manufacturing mill like a steel mill, a paper mill, or something similar. There are thousands or tens of thousands of such plants around the world, and they must undergo regular maintenance every year or so. The cost of the shutdown for these situations is usually measured in opportunity cost; the cost of the product that will not be produced while the plant is idle and undergoing maintenance. This cost is measured in hours, and the cost can be upwards of $150,000 to $250,000 per hour! So the pressure is on minute-by-minute to get the job done. In this kind of situation, the shutdown typically lasts 5-8 days and the delay of a single day is calculated in the millions. If you are only used to longer, more traditional schedules, you might think that in a few short days, "how many tasks could there typically be?" but it’s not at all unusual for such a shutdown to have 2,000 to 4,000 tasks, each lasting from 15 minutes to a couple of hours. Resource assignments here are done by skill but resource leveling is rarely done on personnel. With the cost per hour being so intense, it does not matter if you put more people on the project, just get it done in a hurry. Resource leveling in this situation is often done for highly constrained bottlenecks. For example, “we can only fit two people in the electrical room, so that’s got to be managed discretely”.

Ok, we now have three kinds of examples, and there are many more, but these three will serve the

purposes of the discussion just fine. In type one (Software development), we get tasks that are typically

a day or two days to two weeks long. In type two (EPC), we get tasks that are weeks or months long. In

type three (Plant shutdown), we get tasks that are measured in units of 6 minutes (1/10th of an hour), 10

minutes, 15 minutes (1/4 of an hour), up to a couple of hours long. It’s obvious that in some cases, short

tasks make sense and in others long tasks are more appropriate. Following the same logic, sometimes it

makes sense to have a huge number of tasks and sometimes it just doesn’t.

Factors in choosing your project resolution

With these three distinctions, it’s easy to see that the two-month EPC project task would look ridiculous

in a six-day shutdown schedule and that a 15-minute task would be out of place in the EPC or Software

project. But aside from referring back to this article and saying, “Vandersluis says it’s a software project

so tasks can only be 1-10 days long,” (and please, don’t do that) what characteristics of the project tell

us what level of resolution to choose? Let’s take a look at a few obvious ones:

How long is the project?

Let’s start with the most obvious. If your project is expected to be a few days long, such as in our

Shutdown example, then having tasks that are several days long makes no sense at all. Starting

with a top-down approach is often productive when we think about sub-dividing the scope.

Use work-breakdown structure thinking. Start with the major components. Think about having

no less than 4 and no more than 20 items.

Is it a rule? No, of course not.

It’s common sense. Less than 4 makes you wonder why you divided the work up at all and

more than 20 is too hard to hold in one’s mind at one time. Personally I go with no more than

8 items per WBS element and that’s because of some article I read years ago that suggested

that an octagon was the most complex simple shape the mind could immediately recognize.

Think about that for a moment. You can identify a circle, a triangle, a square, a pentagon, a

hexagon which has 6 sides, a heptagon which has 7 sides (ok, that one is hard to visualize) and

an octagon.

Can you identify a 9-sided shape without counting? I can’t. It’s called a “Nonagon” for you

trivia buffs.

So, personally, I strive for the 8-item limit but my rule of thumb is 4-20.

For each element that you looked at, think about how you should divide up the work. Again, think of

the 4-20 rule. But knowing when to stop is the secret. Newer project managers will sub-divide and sub-

divide and sub-divide until every step down the corridor is a managed task. Some good watershed

questions you can ask yourself about the length of a task could be:

What action would I take if this task was late? If the answer is ‘nothing’ then it’s a good indication that the task you’re thinking of is too small to be worth managing. If that’s the case you are looking in too much detail. Back up a level, take a step back, and see if you are done.

Will collecting the data on the update of this task take longer than the task itself? We do not always think of what kind of effort it will take to manage a scheduled task, but it’s

worthwhile to think about even if for a moment. If it’s going to take more effort to manage the task than it will take to complete, then that is a good indication that the task is being defined at too fine a level of detail.

How long is this task? When we are sub-dividing work, sometimes we lose sight of how miniscule a task becomes. The big phases at the top level were perhaps weeks long, but as we get down a couple of levels of granularity, we can easily fall into the trap of defining a task to be managed that is only a few minutes long. When we get to tiny tasks, we have to ask what the benefit would be of managing them.

Let’s apply a reality check to what I’ve just talked about. In a two-year EPC project, if a one-week task is

a day late, it’s almost certainly not worth taking action over. In a six-month Software project, a one-

week task that is a day late is probably not worth taking action over. In a six-day Shutdown project, a

one-week task that is a day late is a massive emergency. In other words, a one-week task in the EPC

project may be too fine a level of detail; in the software project, it’s probably just about right; and in the

Shutdown project, it almost certainly needs to be broken down into more detail.

How many resources are involved? I know we are just working on the scope, but when we look at what kind of resolution we require, it’s

worthwhile to think about how many people will be working on a task. In a large EPC project, for

example, we may have dozens of workers from one skill involved in a phase of work. But when we end

up with many different skills in the same task, managing that task becomes very challenging, if not

impossible. So, in that situation, tasks that require many different skills probably have to be divided up.

In a software project, we tend to think of almost every individual as a highly technical resource with

unique capabilities. Plus, in software projects it is common to have many tasks that are re-assignable

within a department but only one task assigned to one person. So when we have tasks that are

allocated to a one-person level of a particular resource group or department (for example interface

programming) we are close enough to say that we do not need more detail.

How are resources managed or sub-divided? How resources are managed is a big determinant in how to sub-divide your tasks. In large EPC projects,

for example, projects are often cut up into sub-projects that are parceled out to huge sub-contractors.

In this situation we need to do a couple of things:

Define the work in a way that lets a project manager oversee the sub-contractor with confidence that progress being made is a big factor.

Define the tasks in a way that the sub-contractor’s project management and engineering staff will understand what they mean with no ambiguity.

Ensure that the level of resolution that you have adopted as your standard is understood and agreed to by the sub-contractor.

When we look at white-collar projects such as software, biological research, or engineering, we are most

likely to encounter a Matrix Management structure where project managers own none of the resources

and we must work across department managers who allocate those resources across many different

projects. In this case, the key questions would be:

How many projects is a resource likely to work on across a single day? How long does it take an employee to switch from one project to another? Is the work defined such that both the employees and the resource department managers

understand how to allocate the right skill to it? When we look at a Shutdown or Construction project, we tend to work across crews that are purpose-

built. In these situations, a Resource Team Leader might be managing the Electrical Team (even if that

team includes carpenters and pipe-fitters), a Plumbing Team, or a Boiler Unit Refurbishing Team. The

work has to be organized in such a way that the crew can be kept busy throughout the shift and that

they won’t arrive on top of another crew already working in something in that area. Given the intense

pressure of getting a Shutdown project complete, the work is often organized by work first, scheduled,

and then regrouped and sub-divided by a Resource Team Leader so each team leader can walk around

with only their tasks in one document and with the entire project in context in another. So tasks have to

be defined in a way that is understandable by the employee and by the Resource Team Leader. Tasks

here are probably defined down to the hour or with even more granularity to the tenth or quarter of an

hour.

How quickly can you gather data and how much effort does that take? It sounds like a silly question when you’re used to seeing your project data all nicely lined up at the end

of the week to be reviewed, but when you are trying to determine the level of resolution of your

project, this can be a key question. For example, when you are working through numerous sub-

contractors, it is likely that you will get some kind of weekly or monthly update. In fact, building the

project management update clause into your contract is essential. In this situation you have to integrate

the data from these different companies into your own, validate that the progress data makes sense,

and then do your own analysis and reporting. In an EPC mode, this is probably a monthly occurrence.

In a shutdown project, you will need to be updating your project every shift, update it quickly, and get

the updates to the Resource Team Leaders in the middle of the next shift. In this situation, project

personnel swarm all over the plant all during the shift, gathering data in as close to real time as they can

and having Resource Team Leaders and Foremen use ‘take-down’ sheets to ‘take-down’ the progress of

their assignments. In a software or research project, you are probably working on a weekly schedule or

something like it with individuals reporting their own progress and going through approvals over a day

or two.

This is an important point to consider when you are looking at how many tasks to have in your project,

because there is a cost to gathering the data

So thinking about how quickly you can collect, approve, integrate, analyze, and report the data on a

regular cyclical basis is key, as is the consideration of the cost of collecting the data and the return on

investment of that data being collected.

How often will we update?

Here are two keys to determine how much data you can collect and include:

a. Think about how you will collect your data.

b. Think about how often you can reasonably update your project and provide management

with the decision-making tools required to guide the project and the resources in the right

direction.

I’ve seen some project managers insist that they want to move to ‘real-time’ project management and

project collection and while this may be possible in theory, it is terribly difficult to realize in practice.

When we look at project management data we make some assumptions. We assume that:

The data is all there We do not expect to be looking at some tasks that are updated and other that are not

The data was all updated at a similar time We do not expect that half the tasks were updated a few minutes ago but the other half have not been updated for two weeks

The data has all had some level of approval We expect the project manager to stand behind the data being presented and that he or she is able to say “This is a fair and accurate representation of the project.”

The data belongs together We do not expect risk to be blurred with costs and with resources unless we have specifically designed our reports and analysis that way.

I often ask executives who are excited about the concept of real-time project management what they

will do if we could overcome the points I just raised above. “Are you prepared to take management

decisions all throughout the week?” I’ll ask. The response should depend on the level of resolution. In a

shutdown project the answer had better be ‘Yes’. In a software project, the answer is probably ‘No,

we’ll do that weekly’. And in an EPC project the answer would be, ‘Monthly’.

At some point the law of diminishing returns kick in to say, “Delivering project reports any quicker will

not give us any increase in efficiency.”

Reviewing your work

You have now had some food for thought, you have used the Work Breakdown Method to sub-divide

your data, and you have watched for some of the warning signs that the data is too finely defined. Now

it is time to lean the schedule up against the wall, step back, and look at the project with some

perspective. Amazingly, many project managers never do this. They get so caught up in getting the last

details defined and are so busy sub-dividing tasks again and again that they push themselves right up to

the go-live deadline and never look up to see whether what they have made will be a nightmare to

manage.

In some cases, executives are sure from all that MBA training that “more detail is better” and they are

pushing for those 5-minute or 15-minute tasks on six-month–long projects.

Changing the project before it starts is always easier than at any time later, so build time into your

schedule-building activity to rework the schedule if required.

Is it too much?

Sometimes project managers look at the scope of what they have created and realize that they are at

too fine a level of detail. If that is the case, the fix is obvious. It may be a lot of work, but you will thank

yourself later to make the schedule simpler by moving up a level.

Sometimes the picture is not so easy. In some cases, it is only once the entire schedule is assembled

that the project manager can see how complex it is. Complex projects are, by their very nature, riskier,

and risk in today’s economy is a key selection factor for projects. Some questions that are worth

considering before such a complex project gets underway might be:

Can we do it in pieces? Some risky projects can be broken up into smaller bite-sized portions and as smaller projects, their risk goes down. However, if you are using this strategy, each discrete project should have its own value when it is complete.

Should we rethink the scope? Sometimes the simplest actions are to go back to the designers of the work in the first place, explain the complexity that seems apparent in the schedule, and see whether the work can be restated. This often leads to innovative thinking that would have never had a chance to occur.

Should we do it at all?

Some projects were never meant to be, and the cheapest time to cancel them is the day before they

start. If the risk of the project is only now apparent, better to realize it now than later. When you

weave the findings of doing your schedule back into the Project Portfolio Management (PPM) process,

you might find that the risk of the more complex project has the work score much worse in a return-on-

investment scale.

A nimble… no, an Agile project

I promised to say a few things about Agile project management and if you are an Agile fan and you have

read this far, I appreciate your patience. Managing software projects through the Agile method is

something of a philosophy, but it is a more and more popular philosophy with those who have been

burned on massive software development projects that failed.

In an Agile software development world, we try to break our project into bite-sized, one-to-three week

“sprints” and the goal for each mini-project is to end up with useable code. In this case we are working

within some fairly well-known constraints so that our level of resolution is pretty much picked for us.

We have a one- to three-week window, the resources are available to us, and we are going to assign

work to each resource. The number of possible tasks that we can define in that structure is finite and

this lends itself to keeping an appropriate level of resolution. Yes, you can get into trouble in Agile by

defining tasks that are much too short. “Define Field1: 10 minutes, Define Field2: 10 minutes, Define

Field3: 10 minutes” etc. but it’s much less common.

Agile was designed for a corporate development environment where we are creating software for in-

house use, and its use is often extended to commercial software development. (We use the method

here at HMS for our own development of TimeControl.) The Agile method results in a more

maneuverable and nimble development department but it is not going to be applicable to every industry

or even every software company. If you are doing project management in a software environment then

my recommendation is to read up on Agile, learn from it, and then adopt those elements (all, some, or

none) that will make you most effective.

Wrapping up As with most aspects of project management, there’s no set answer to questions that at first seem to be

so obvious. How many tasks you have in your project and how long each of those tasks should be is

something that you need to look for yourself to decide … but decide you must.

Choosing your project level of resolution is a project management responsibility that can be a key

success factor in the management of the project schedule.

Dashboard Directions

There’s no doubt about it.

Dashboards are all the rage.

Whether it’s a bar chart, a

histogram, a pie chart or a traffic

light warning view, executives

seem addicted to the instant

response of a dashboard. With

more and more pressure in our

business culture to deliver faster

and faster results, the demand

for dashboards is not likely to

abate anytime soon.

The project management

software industry is a poster

child for this kind of display

because project management

data is perfect for dashboarding. When we look at what kind of data would be required for dashboards,

we look at several qualities:

Is it grouped together in ways that it can be displayed and understood? Is it timely? Is there some approval or vetting process for the data? Is there numeric or time/date data that can help make variances?

That’s exactly what we find in project management data from an Enterprise Project Management (EPM)

system like Microsoft Project Server.

No surprise, then, that most EPM systems including Project Server have some dashboarding capabilities.

In the case of Microsoft, the capabilities come courtesy of SharePoint Server in the Business Intelligence

Center. This type of system can look into SQL-based data and generate an incredibly wide range of

graphical displays. And, just like a kitten, there’s nothing an executive likes better than a shiny new toy.

The desire by senior management for instant feedback from projects can be so severe that many Project

Management Offices are pressured to deliver the display before the underlying data is even ready.

“Can you make us an EPM Dashboard?” I was once asked by a senior IT executive while I was in their

offices helping to design their EPM environment.

“Sure,” I replied.

“Could we have it by Friday?” asked the exec to my surprise.

“Um, sure,” I answered. “Well, not this Friday. But a Friday sometime in the future.”

He wasn’t at all amused by my humour.

It was not an unintelligent manager, but it underlies the pressure such people experience to enable

rapid decision making.

Dashboards are so visually stimulating, we often forget that they are supposed to represent something

that generates the display. So, before running out to find out how to make a dashboard and before you

start spending too much time picking out color palettes of what color your icons should be, let’s go

through a few common challenges in the dashboard arena.

Wizard of Oz Syndrome

Remember the Wizard of Oz when they finally

pulled back the curtain and found just a regular

guy who was pulling the levers and turning the

dials to generate all the impressive “magic”?

Beautiful displays that are driven by human intervention are something we see all the time in

dashboards. A great deal of work goes into the design and presentation, including great graphics, great

icons, great colors and even animation and sound effects. The problem is that no one has traced a path

between the data and the dashboard and the result is that someone has to sit at a desk and decide

manually what indicator to make which color.

When looking at an existing dashboard for the first time, it’s always worthwhile to ask to see the raw

data that made up the display. “What does this mean and can you show me where this indicator is

driven from?” is a key question. Do a mini-audit of a few indicators, tracking them back to their

component data.

The same principle holds if you’re designing a dashboard. For every indicator, there has to be a trail

back to some source and it is best if it’s documented. If the dashboard is driven by Bob filling in a

spreadsheet with how he feels about the projects, just have him tell you. It’ll be faster.

Measure everything

“If we can measure it, we will put it on the dashboard,” seems to be the mantra of some dashboard

designers.

It’s easy to get caught up in the technology of dashboarding and there’s a certain visceral thrill when you

locate some data that seems measurable and understandable and you make an indicator out of it.

Suddenly instead of a boring old list of costs, you’ve got thermometers filling up with red or tachometers

revving into the red-zone or arrows in different colors. Don’t think this is fun? Give it a try in Excel for a

half-hour by using the new Conditional Formatting functionality of Excel 2010.

Problems happen when someone who’s making an executive dashboard gets so caught up in their ability

to make an indicator that they don’t stop to look and see if they should be making it at all. It’s not

always "how do you do it?"; sometimes it’s "should you do it?"

Once there’s so many visually stimulating indicators on the page that it looks like the dashboard of the

space shuttle, you know you’re either going to need years of training like an astronaut or you’re going to

need to make life simpler.

Here’s a basic rule that should make for fewer displays: Every indicator needs a potential action; every

one. So, if you have a traffic light indicator and it’s red, then there needs to be an appropriate action

that someone is supposed to take when that happens. It might be a simple “When this light turns red, a

project manager must show a detailed report to the head of the PMO.” Regardless of what the action is,

there needs to be one.

Half-baked plans

You wouldn’t eat a cake that only had half the ingredients, especially if you didn’t know which half were

missing. On a dashboard, how do you know you have

all the data?

Let’s take an example of looking at resource capacity

reporting. The resource traffic light has become red

for IT (isn’t it always?) Now management wants to look at the problem and when they look at the

detail, they see the obvious

answer. The indicator must be

red because IT is so over-staffed!

This first histogram shows the

problem. The red line shows the

capacity of the organization.

The stacked histograms show

the combined requirements

projected by adding the

requirements of all projects

together. If this is the dashboard that we present to management, the decision to either accept a lot

more work or to reduce our staffing levels immediately would be obvious.

Ah, but hold on a moment. Just

before the reduction in staffing

levels plan goes into effect, it

occurs to someone to check to

see if all projects were

represented in the dashboard

view.

They were not.

There were some projects that

appeared in the legend but no

results for these projects were displayed in the histogram. Where were the results? Perhaps these

projects were not yet published. Perhaps the full project scope was still being determined. Perhaps the

resource requirements had not been defined at the appropriate level. When the data is revised, we can

see in the second histogram that in fact, there is now more work than people and we should be

considering hiring more staff, adding some contract capacity or delaying some projects into the future;

the exact opposite decision we would have made from looking at the same view with only part of the

data.

The problem is not the design of the dashboard; nor is it the quality of the data. It is the completeness

of the data that is the problem. In this obvious example, we can see the problem with our own eye, but

imagine a project environment with hundreds or even thousands of projects or sub projects in the same

dataset.

Making a decision with only part of the data is often going to result in an inappropriate decision.

Making a decision where the decision maker doesn’t even know the data is incomplete is, at best,

disempowering to them.

We can solve this with a review of the data in some kind of approval process or, perhaps, with the

combination of a validation process and a database-based indicator that tells us that we are only looking

at a partial image of our indicator.

Best before dates

If you’re like me you reach into the refrigerator and grab the closest cheese to you, but shouldn’t you be

checking the "best before" dates? While we’re on the subject of the source data that made up that

pretty picture on your dashboard, do you have any notion of how old the data is that is generating that

indicator?

It’s not uncommon to do an audit of a dashboard indicator only to find that the data that originates the

indicator hasn’t been updated in a long time. It’s often a sharp executive who picks this up in a review

meeting. This is the kind of person who brings not only their notes from the last review meeting but

also copies of all the handouts that were given last time and their practiced eye looks over the last

handouts and the new handouts and compares the data.

Identical indicators mean either that things haven’t changed (unlikely in most project environments) or

that the data hasn’t been updated

(much more likely in a lot of

organizations). For those in Finance

who often live and die from the

results of their spreadsheet, or a

massive spreadsheet farm made up

of many sub-ledgers, this is a

common error. Project managers

and those who look at project data

may be less likely to catch such errors

without stringent care.

The worst case scenario is one where some of the data has been updated and is current and some of the

data has not been updated at all. So, perhaps the forward plan was updated on half the projects, and

the actuals for the last period were posted to those projects but the other half of the projects did not

have actuals posted or have their plan updated.

If decisions are going to be made on the dashboard view or the resulting data that it came from, how

current that data is should be displayed somewhere.

This kind of problem can also be resolved with some basic checks and balances in the data which can

then be displayed on the dashboard. For example, a simple test could ensure that:

a) All timesheets were collected for the displayed period, and b) the total timesheet hours collected are roughly equivalent to the total hours displayed.

Data pedigree

The prettier the display, the less likely we are to ask, "Where did that data come from and how reliable

is it?" There’s something about neatness that counts when we put the data into a professional looking

graphical display. For those who are creating data from a database, they can often be kept at a distance

of where that data arrived from. A graphical designer finds a couple of useful looking fields and ways to

calculate indicators from them and can easily neglect to ask if these fields are populated through a

validated process, with any kind of oversight, by calculation or if the data is not considered “corporate

quality” by the people entering it.

Perhaps we’re working on a software development project and a list of outstanding and newly added

software issues and there is a great SharePoint list of issues that are created by the QA department as a

piece of software nears a release date. This kind of list can be a key indicator of how ready the software

is for release. If, however, many different groups are using the same list for new functionality ideas and

enhancement requests, just counting the list of issues will give an inappropriate indicator because the

list has become polluted with data used for a different purpose.

Data that is going to show up on an indicator on a dashboard has to have some process and some

validation of its quality.

Are we looking at the whole picture?

Let’s go back to that dashboard traffic light report and look at the IT line again.

Let’s imagine that IT has red lights for both the schedule and

cost indicators on a particular year-long project because it’s

June and both indicators are off by more than 20%!

The Chief Financial officer has looked at the detailed results already and he’s quite upset. The January –

June actuals show the tale:

($,000s) Jan Feb Mar Apr May Jun

Budget 80 100 120 120 120 120

Actual 100 120 140 140 140 140

Variance 20 20 20 20 20 20

Cum Variance 20 40 60 80 100 120

So far the project is already $120,000 over budget and it’s only half-over! At this pace, says the CFO, the

project will cost 18% more than its original $1.3 million budget and perhaps they should cut their losses

and cancel the project.

If we look in more detail, however, the picture looks very different. The projected scheduled and costs

until the end of the project look like this:

(,000s) Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Total

Budget 80 100 120 120 120 120 120 120 120 120 100 80 1,320

Actual 100 120 140 140 140 140 120 100 80 40 0 0 1,120

Variance 20 20 20 20 20 20 0 (20) (40) (80) (100) (80) (200)

Cum Variance 20 40 60 80 100 120 120 100 60 (20) (120) (200)

Now we can see more of the story. The project is running faster than had been anticipated. In fact, it is

going to finish in mid-October instead of in December and is projected to finish $200,000 under budget.

This is the challenge with simple dashboards and how they’re interpreted. The dashboard was

completely accurate but the reason it was red was good, not bad.

Dashboard indicators need to alert executives that action needs to be taken and where to look, but they

should also lead that same executive to the more detailed data that will show the whole picture.

Gamers galore

Ok, so now you have a few things you can do to make sure your dashboards do not mislead

management to inappropriate decisions, and that’s a huge step. But, be advised, as soon as dashboard-

type indicators are made available, people will use them to their own advantage. It’s completely

understandable that people will game the process if they can by skewing data under their control to

have them not look bad.

There’s no preventing people from trying to game the process, but there are a few techniques to avoid

the events of these gamers:

Change the process

You can make it tough to game the process by changing it all the time; trying to stay ahead of

those who think they have the process figured out. Everyone in the search engine business of

Search Engine Optimization knows this one but the challenge with this is the enormous amount

of work it takes to keep changing the process and training everyone in the changes.

No carrot, just stick

Another option is to discipline those caught gaming the process. This is a tough one. People

who outright lie about their data should get into trouble, but punishing those who are just

finding loopholes in the process is typically bad for morale.

Checks and balances

This is typically the most powerful tool against gamers. If you have data from different sources

that has to balance against other data, it becomes extremely difficult for someone to

manipulate just the data under their control and defeat the dashboard process in their favor. Of

course it’s not always possible to find such checks and balances within the data, so vigilance is

always a good thing.

Some basic rules

Ok, let’s wrap up some of what we’ve said. Creating powerful-looking dashboards is technically not

difficult but there are some basic rules you can implement in your dashboard design and project

management process that can ensure the decisions that come out of such dashboards are appropriate

and effective.

Here is a summary of some of the basic concepts we’ve discussed above:

Indicators must trace back to source data Make sure that indicators aren’t just the manually entered opinions or feelings of someone, but that they actually represent something in the detailed data of your environment.

Every indicator needs an action

Every indicator needs an action; every one. Regardless of what the action is, there needs to be one. This will likely also help with keeping the number of indicators to a reasonable level.

The data must be complete or show that it’s not

Make sure that it’s is clear from the display that the data is either complete or incomplete so that inappropriate decisions aren’t made while looking at only a partial picture.

The display must show its timeliness

If it is possible to have some data updated and other data not, then the refresh date of the data must show up on the dashboard in a way that inappropriate decisions based either on old data or on a mix of old and new data are avoided.

Check data quality in an ongoing fashion

A dashboard should have regular reviews of the data that drives the indicators and regular updates to avoid people from gaming the decision-making process. Some organizations will implement a regular auditing process that looks at key indicators and traces back from their results to the source data, checking the formulas and the quality of data to make sure it has not changed. You can’t do this all the time, of course, but a regular review of what makes those pretty traffic lights turn green, red, or yellow is a healthy idea.

Enterprise system best practices

I mostly write about enterprise timesheet or enterprise project management systems, and the most

common phase of deployment that I talk about with such systems would be either the selection or

configuration phase: talking about the strategic perspective. This article is much more about

operational practices and isn’t specific just to enterprise timesheet or project systems like Microsoft

Project Server. Rather, it is about enterprise systems in general, though the subject matter can certainly

relate to almost all Project Server deployments.

When we encounter already-deployed Project Server systems or we talk to existing clients, we often ask

questions about how the organization deployed and has supported the system and its environment.

When we got started in the industry, these were simple conversations because the project software we

would install would always live on the end-user’s PC, and care of the system was always a local concept.

These days that’s rarely the case. Enterprise systems are simple at the interface or display level where

end users can typically access the functionality through a web browser in what looks like any other web

page. As simple as these systems might be in front is as complex as they might be in the back. The

technology required to display that interface likely has numerous layers, depends on multiple sources

for the technology and infrastructure, and (if that’s not enough) is probably being updated all the time.

But, there are some basic best practices that can give you the best chance of maintaining a high degree

of reliability in your enterprise system:

Find an owner

In fact, we have to divide this into two owners because any successful enterprise system has both a

business owner and a technical owner. Only when the business owner is an executive in the IT

department and the enterprise system is primarily for that department can the owners be the same. So,

let’s take this in two parts:

Find a business owner

This person should be an executive level or senior management level person who has a vested interest

in the results of the project management system. The benefits that the system must deliver or the

business challenges that the system must overcome will have to be benefits and challenges that affect

this executive directly. And, before someone even says it; no, typically it can’t be a committee or

multiple persons. The responsibility has to lay somewhere and that almost always means one person.

This person might also be the executive sponsor for the implementation of the system but might not be.

Often the executive sponsor is not the ultimate business owner of an enterprise system. Even after the

deployment project is over, the business owner will still own the system and, should they no longer

require it, either another business owner needs to be identified and must commit to the system or the

system should be retired.

Find a technical owner

For enterprise level systems, just having a technician available is insufficient. Remember, enterprise

systems depend on many layers of technology. The technical owner must be a senior enough manager

or executive in the IT department that he or she will be able to immediately interact with the owners of

those other layers of technology. That may include senior people who own the SQL Server database,

the database server that SQL Server is installed on, the application server(s) that Project Server is

installed on, the networking, the Web server or server farm, the Internet connection, the firewall, Active

Directory and Exchange servers, Security servers or systems, and the client-level operating system

image. Someone senior must be able to represent this enterprise system to those managers who

control other aspects of the environment.

Be purposeful

Make sure that Project Server a) has a purpose and b) is fulfilling its purpose. Sound obvious? It’s not.

All too often enterprise systems are acquired for the wrong reason, and it falls to someone in IT to look

for a purpose to apply the system to. The person signing off on the business purpose for the enterprise

system should be the business owner, though others might be involved. I always ask such executives a

question I’ve used for years, “What business decision can you now not make or can you only make with

great difficulty, the making of which will be enabled by the deployment of this system?” Once the

business requirement (note that I didn’t say the desired functionality) is settled, make sure that the

enterprise system is actually fulfilling that requirement. I meet a lot of people who have a shopping list

of functions but little understanding of what they are trying to accomplish with them.

As the organization evolves, make sure that the business owner comes back to this basic concept. Just

the deployment of an enterprise system like Project Server can fundamentally alter the business it is

deployed into, so it’s not surprising to find that the organization’s requirements for a system can

change.

It is common to come into an organization several years after Project Server was adopted and deployed

only to find it impossible to locate someone who knows why it is important to the organization. The

system is in use to be sure. It is being carried forward on sheer inertia but the purpose has been lost

and the executives who benefit from it every day don’t realize where that benefit is coming from.

Get it into your enterprise architecture

Several years ago I remember going with one of our technical staff to an upset client’s location. The

instance of Project Server they had installed themselves was causing all kinds of trouble. While there in

person, we asked to interview a number of technical personnel, tracing the system back through its

layers. When we got to the database layer, we were stunned. Instead of being one of the organization’s

standard database servers, the SQL Server version on which they’d installed the system was on an end-

user’s PC. Every time they rebooted, turned the PC off or installed something, the database would

become unavailable. This affected literally hundreds of end users.

The organization was a large one so there was no lack of enterprise servers or infrastructure to rely on.

In this case, the problem was easily fixed. It was a good lesson though. Is the system that you are

deploying being woven into the existing corporate infrastructure on which the organization may have

spent an enormous effort getting stable, being reliable, and being secure?

Back it up

I know. This is silly, right? Amazingly and unfortunately it’s not. Enterprise systems can be notoriously

complex to back up as they may depend on multiple aspects of the system to be backed up at the same

time. There is the basic data of course, but also the metadata and configuration data of the

implementation. And any related data from ancillary systems that might have to match the system may

have to be part of the same backup scheme. When we think of Project Server, we have to think of

backing up not just the project database(s) but also the SharePoint Server database. In Project Server

versions before 2010 we might need to back up the Global Template. Even now there might be

elements of templates that are on individual PCs.

And just backing up isn’t enough. When the systems change or are upgraded, do a database restore at

least once. I remember years ago being with a client whom we had helped design a backup strategy for.

He shut down the server, pulled out the hard disk, put in another hard disk and then looked at us and

said “There. The hard disk just crashed. That’s a newly formatted hard disk. Please restore my Project

Server.” I was taken aback, but more so because I realized how good a request it was, and the more I

thought of it, the more I realized how shocking it was that no one had ever made the request before (or

since). So, do a restore test at least once. We were able to restore that system by the way, but it didn’t

go back in as cleanly as we’d suspected it would and we had to update our backup procedures.

Staging/Production

“All the world’s a stage, and all the men and women merely players,” said Shakespeare a long time ago.

In this case, the stage is more about staging and that’s key for any enterprise system. Once the system

is in production, you will want to try new configurations, add new customizations, try new reports, links,

fields, and other changes. You will have updates and upgrades and all of these should be tried first in a

staging or development environment before they are inflicted on the users in the production

environment. Something as basic as a browser update or a database update can throw enterprise

systems for a loop, so make sure you keep and maintain a staging environment that’s separate from a

production environment. In this day and age of virtual servers, this may be easier than it might have

been in the past. An entire environment can now often just be cloned from the production system, but

that may be easier said than done depending on how you have deployed. Remember lots of different

parts of the technology puzzle may be referenced even though you have copied an entire server.

Monitor, monitor, monitor

There are lots of points of oversight that can be used to monitor an enterprise system. First of all,

making sure Project Server is available to end users is critical, and ensuring that the appropriate

technical staff are notified as quickly as possible if it is ever not available is also essential. Thankfully,

there are many tools on the market for ensuring that the system is functional and available that can

automatically notify technical staff even if end users haven’t noticed the problem yet. But there are

other aspects of monitoring that are also important. It is good to keep a watch and a log of the health of

the application, including the amount of memory it is using, the amount of the CPU(s) it is taking up, any

errors that the system may have reported even if it recovered from them itself, any restarts of the

server required, and the relevant health of other elements of the technical infrastructure. Knowing, for

example, that IIS is having technical issues might be very important to maintaining the availability of

your enterprise application.

Even small changes are changes

The technology on which Project Server is based changes day by day. It’s impossible to avoid all of these

changes. The Windows Server operating system often receive updates every few days, SQL Server can

receive updates every few weeks. Individual Windows client operating systems, their virus scanners,

firewalls, and Internet Explorer and its add-ins get updates on a regular basis. Any part of the chain

between the data and the end user is a potential point at which the application can break down, so

create a structure to manage changes throughout the entire stack of technology. This can be a

challenge, as many different enterprise applications may depend on similar aspects of the stack. We

had one client who innocently updated Project Server awhile back only to find that the entire SharePoint

Server environment was brought down. Clearly there had been an error in how the Project Server /

SharePoint Server update had been applied. While there were complete backups and no data was lost,

the upgrade process did not have an instant rollback provision and thus the effects were devastating, as

they took days to reverse. At another organization, we had a client who had updated another

enterprise application to find that it absolutely required all users to upgrade their browser version only

to discover that other enterprise applications already in use at the company did not support the more

recent browser version. It was the proverbial rock and the hard place. In the end, they had to roll back

the upgrade of the enterprise system and wait until all the enterprise applications could move forward

with a new browser upgrade.

Sometimes it’s better to look integrated than be integrated

Sales demonstrations always make the integration of multiple tools look so easy. Hey presto, the data

starts here and ends there! Establishing a link between highly flexible tools like Project Server and other

enterprise systems like Finance/ERP is tough enough, and we always recommend that both systems be

in production and stable before any links are established. Once they are underway, however, it’s even

more important to monitor any changes of the two systems with a mind to making sure they will

continue to link properly. With any upgrade of either system, there may be data changes, structure

changes or different technical requirements. There may also be new features and benefits that are

possible, but make sure the existing linking functionality is tested in your staging environment before it’s

rolled out to production.

Document, document, document

The people who were there when Project Server was selected and deployed won’t be in those roles

forever. In fact, if they did a great job, they’ll be off managing the next enterprise deployment that the

organization needs. So documenting the configuration decisions, the projected benefits, the operating

expectations, and parameters that were used to make those decisions is essential. On the future, others

will be looking at this system and scratching their heads saying, “What were they thinking?” Make sure

you tell them.

Enterprise system documents should be living documents that are updated with every upgrade, each

change in business or technical owner, or any major change in either the operating structure or the

business requirements.

Look before you leap

It’s the advice we give people diving into a murky lake for the first time. Is it shallow? Are there rocks

just below the surface? Enterprise project management systems like Project Server can indeed bring

complex data elements into one place where decisions based on that data can be more effective and the

benefits of those decisions can make a profound difference to an organization. But you need to do your

homework to ensure that you are operating your enterprise system in a way that you can get the

benefits you need without exposing your organization to costs and risks that can quickly wipe out the

value of those benefits.

The Project Management System Maturity Model By: Chris Vandersluis

The Project Management Maturity (PMM) model is a pretty hot topic these days. There are waves of consultants who are making a good living helping organizations assess their “project maturity level” which is pretty much always displayed hierarchically with more mature always shown as being better than less mature. Proponents of the concept say the PMM model shows the capabilities of an organization to manage projects. There’s a whole conversation to be had about how organizations become more effective and I’m not sure just climbing the Project Management Maturity model necessarily gets you there. But that is a subject for another day. Whether or not you're a fan of the PMM model, there is another kind of maturity model that I've seen with organizations who use Project Management systems. When we work with organizations who are deploying a project management system, it’s very common to find that the desire of organization is to reap the benefits of every single element of the new system they’ve just had demonstrated by the vendor. The client sees reports and screens and workflows and functions that they’ve only ever dreamed of and they imagine a world where all that functionality works as smoothly in their organization as it does in the sales demonstration. It is usually unclear to the client that the demonstration data and demonstration configuration that is being demonstrated was carefully developed in order to showcase as much of the product as possible. In the case of Microsoft Project and Project Server, this may extend far beyond the single product to include the entire stack of technology. The client sees screens that initiate from Windows SharePoint Services or from Microsoft Office SharePoint Server forms. They see functionality that touches Active Directory or SQL Server Reporting Services. They might see workflow from BizTalk Server or Windows Workflow Foundation and displays that come from PerformancePoint. The flow of data might follow a storyboard or a use-case scenario that makes understanding the potential benefits easy but understanding the underlying technology more difficult. When we arrive to actually deliver the functionality the client is interested in, we need to temper their desires to deploy everything at once with a reality check. The client needs to decide how it wants to do business before we can even consider configuring such functionality and whether it can be delivered out of the box, with configuration or with customization effort. There are some clients who are insistent that they deploy every aspect of the functionality they’ve envisaged and are prepared to dig in and do the design; training, learning and development of that solution as well as find the funding both in time and money to deploy it, but these organizations are the exception. What is much more common is that the client elects to deploy the aspects of its new project management system to the level that it is already comfortable with. As the organization becomes more knowledgeable about both the system and the underlying business processes, it will demand more and more of the system; becoming more ‘mature’ as it progresses. It’s a natural progression. As the organization’s understanding of a project management process that can be automated evolves, its demand for that automation evolves also. This natural progression is just like the Project Management or Capability Maturity models. Knowing that organizations will most likely evolve along these paths has made us very effective at knowing where to put our efforts in making an organization effective. We tend to focus on those project system areas that we know

have a better chance of adoption and of giving a return on the investment given the project system's maturity of the organization. Of course no two organizations are the same, so chiseling this knowledge into a tablet isn’t a good plan. It’s just the most likely progression based on our experience with many companies. In our experience, the natural evolution of use of a project management system comes in five basic areas, although the sequencing of them has shifted in recent years thanks in large part to technology. Let’s talk about the five basic areas to start with, and I’ll cover some of the new shifts that we’ve seen over the last few years nearer the end of this article.

1 – Planning

We almost always see Planning as the first wave. Some organizations never get beyond this. They make a basic schedule, bronze the Gantt chart, and then mount it on the wall of the project team’s office. People refer to the plaque from time to time nostalgically as they remember the fine state of their schedule just before the project started. While I’m being a bit cruel at those who are only using their expensive project management software to make a bar chart, there is certainly value from doing so. Creating an organized schedule tends to make the project participants think about how the work should be put together and is much more effective than doing nothing or just making a spreadsheet list.

2 – Tracking

Next in line in our experience is typically tracking. An organization which is a little more “mature” in the use of their project management system will not only plan, they’ll track their schedules, advancing them on a regular basis with the progress to date and even look forward with projected schedules as the plans advance. For many organizations, stopping here is effective. They’re planning in their project management system, and then they’re working the plan by updating it regularly and even giving useful reports to management.

5. Advanced

4. Costs

3. Resources

2. Schedule Tracking

1. Schedule Planning

3 – Resource Management Once planning and tracking are handled, organizations tend to look to the resource management problem and how it might get resolved by using the project management system. Resources can have many aspects, as I’ve discussed here before, but at the most basic level, resource allocation (assigning the work to resources) is a big step, followed by resource analysis of some kind.

4 – Cost Management

Cost management is the fourth typical area and many organizations never get here. At a basic level, having a cost estimate broken down by phase or better yet by task in the project is a good costing start. Tracking the actual costs either by hours or by dollars is the next level.

5 – Advanced I’ll put a fifth area here for “Advanced” subjects for what might be a wide range of topics that I haven’t put in the other categories so far. It’s not that they’re not important but that when you get to the fifth wave of evolution in an organization, it can go a lot of different ways. So, I’ll put risk analysis, document management, and automated workflows in here. There are also advanced areas in each of the other four areas I’ve discussed so far.

Each of the elements I’ve discussed so far could be extended further and often is as the organization’s

project maturity and the understanding of the automated aspect of its project management

environment increases.

For Planning, the progression can go to multi-project integrated schedules with inter-project links or program management with sub-projects. For Tracking, the organization usually advances from simple percent complete progress, which is

typically the lowest quality of tracking data, to remaining duration. Tracking might also extend to

timesheets to give an exact value of hours worked against the original plan by person.

In the Resources area, we see going from just allocating the tasks to resources to tracking resource

progress usually with a timesheet and then moving to the most requested aspect of EPM, Resource

Capacity Planning. For some organizations, Critical Chain fits in here also, merging the resource and

schedule information into one advanced algorithm.

For Costs, we usually go from the basic budgeting to tracking actual costs along with hours and time to

get budget versus actual variance, and from there to Earned Value tracking, as is done in the Defense

and Aerospace sectors.

Even the Advanced area has advanced topics. The most popular among these are Monte Carlo Risk

Analysis and integrating project management methodology (particularly in the IT sector).

Most organizations progress with all five of the basic elements from the left side of the graphic above in

the order that I’ve just described before turning to any of the advanced areas. Some find that their

particular project management challenge means focusing on one element ahead of others. What is

extremely difficult and rarely successful is trying to be more mature than you are.

It’s very common, for example, for an organization to desire Resource Capacity Planning, yet when you

look at the skills and experience of the organization, you find that the building blocks of creating a

resource capacity planning system are missing. I often use capacity planning as an example of why

knowing where you are on the Project Management Systems Maturity model is so important. In my

experience, this is the single most requested benefit from EPM systems and yet it is almost the last

benefit I can deliver. This is because resource capacity planning requires so many other elements to

work first. In order to deliver projected resource requirements versus availability we first need:

Project plans we can count on

Projects tracked with accurate progress

All tasks to be allocated to resources

Complete and accurate resource availability

All non-project work to be quantified and tracked

Complete compliance by project managers and department managers on work completed, work

projected, and changes in resources.

Whew! It’s no small list, and the corporate culture required to comply with such an environment often

requires change management on a big scale. So, we turn back to the Project Management Systems

Maturity model and clients can make a roadmap of what they need to accomplish.

This is not an exhaustive list of course. We can easily make a third column and then a fourth, but I’ve not done so here because from this point the most common progression is less clear. Each

5. Advanced

Document management

4. Costs

Budeting

3. Resources

> Resource allocation

2. Tracking

> Percent complete

1. Planning

> Basic schedules

Monte Carlo risk analysis

Integrated methodology

Track actual costs

Earned Value

Track resources

Resource capacity planning

Remaining duration

Timesheets

Multi-project schedules

Programme management

organization’s project management requirements will dictate the interest in moving forward in a particular area. I promised earlier in the article to discuss something that has changed in the last few years. The model I’ve described above has stood up for quite some time, but in the last couple of years, movement in the IT industry has made a significant shift in another direction, and that has everything to do with collaboration. At one time in the project management software industry we were very algorithm-centric. Everything stemmed from the critical path schedule, we thought. In the last few years, though, a few things have changed. First of all, the availability of people through the ubiquitous Internet or telephone technology has made it even easier to assemble and communicate with your project team. This has helped change who is on a project management team. While once we would have thought of project team members being people deep within the organization, working in a small windowless room with desks surrounding a massive plotter, now we think of project team members throughout the organization. Team members include those doing the work, of course, but might also include the executive sponsor, the department resource managers, the users, the marketing department. It’s now not at all uncommon to find that the project team extends not just beyond the building’s walls but well outside the organization itself to include sub-contractors, prime-contractors and even the client. Sub-contractors may not be in the same time zone or even the same country. All of this has made communication a key success factor for projects in many different types of industries. That has caused some organizations in industries like R&D and IT, for example, to look at a Project Management Systems Maturity Model that progresses quite differently:

The first element in these organizations is to create a communications plan, and that’s almost always based on collaboration technology like SharePoint Server. These organizations find that from a centralized perspective they can get more benefit from getting their extended project management team to collaborate and communicate than from any centralized planning. The meteoric rise in

5. Planning and Resources

4. Timesheets

3. Issue Management

2. Document Management

1. Communications plan

popularity of SharePoint Server is a testament to how much pent up desire there is for getting people to work together. The progression from a basic communications plan then often goes to document management—one document of which might well be a project schedule. It’s turning the classic enterprise project management progress on its head, but you can see for some organizations how attractive this might be. Get a handle on the contracts, documents, emails, meetings and other communication, and efficiency increases very quickly. Don’t get a handle on communications, and the loss of efficiency might well be serious. From document management, it’s a short step to managing issues and doing change management—which for IT and R&D means managing one of the most potentially damaging aspects of a project. Surprisingly, timesheets come next. In fact, sometimes timesheets come even earlier. When our organization first got started in the timesheet business with our TimeControl product, we were quite certain that organizations who needed a timesheet like ours were those that were already mature enough in their planning and tracking process to be able to take advantage of it. You can imagine our surprise to find that many organizations want to deploy an enterprise timesheet before they deploy an enterprise project management system. When you look at the change management challenge of each it becomes clear why. Most users will adopt a timesheet grudgingly but quickly. Getting a 1000-person organization to accept a centralized timesheet system takes a matter of weeks. Getting the same 1000 users to accept a centralized project management system can take from months to a couple of years. So, even though the centralized planning isn’t established, the organization can still get tremendous benefit from centralized timesheet data. Finally, these organizations turn their attention to the core project planning exercise. This is not to say they haven’t been doing project scheduling so far but it won’t have been highly centralized. Just like the first Project Management Systems Maturity Model, each of these elements can carry advanced topics, too. Communications plans often progress to more integrated communications systems, including instant messaging, email integration and more. Document management often progress to workflow management and forms integration. Issue management usually evolves to management of lists of all kinds and an integrated change management process. Timesheets evolve from task timesheets to links with Finance, Payroll, HR and ultimately links back to the enterprise project management system for auditable tracking data. Planning and Resource Management tend to evolve just like my classic Project Management Systems Maturity model. There’s no “right” way to advance in your use of your project management system, nor is there a “wrong” way. As I’ve said in these columns before, what is most important is that you look first at what you need to accomplish in order to be more effective as an organization and from there design the

solution to that challenge. What is important is knowing you have the building blocks from the basic elements before you start building something more advanced. I’m often heard saying that we need Project Management 101 before we move to Project Management PhDs. Remember that the use of a project management system is only one aspect of a possible solution and it’s up to you to decide how “mature” you should be and in what areas in order to make the management of your projects more effective.

Resource Management

Resource management is the most popular reason organizations will switch from individual

project management to enterprise project management with systems like Microsoft Office

Project Server.

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) that 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 like Microsoft Project, 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 personnel are lacking in SQL Server 2008 and that is the skill needed for the next project, then you’re still 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 that some get the resources and some don’t? Should some tasks be prioritized so that 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. The term "Resource Contracts" refers 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 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 say. 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 costs in terms of effort. And it paints 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 Office SharePoint Server 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 that 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 straightforward. After all, there are tools within the Microsoft EPM Solution for all these aspects of resource management. Resource leveling, resource allocation, resource loading, skill scheduling are all referred to in the basic functionality of Project Server or even just with Project Standard or Professional. Multi-project resource allocation can be done with the Resource Substitution Wizard or the Team Builder in Project Server. Resource tracking can be done with the timesheet in Project Server. Resource Contracts don’t have much of an interface by default but the whole idea of Proposed vs. Committed Resources is in that area so a more robust interface for dealing with resource requests could be done with a web-based form with Office SharePoint Server and tie into the functionality directly. Even Resource Sub-Contracting could be addressed with functionality from Office SharePoint Server. 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 full-time 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 got a simple project here in Project Professional 2007. 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 Project’s Resource Leveling algorithm:

Again, things are perfect. 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’s well it seems 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?

Project 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 fault of Project. This is just how resource leveling works with virtually every scheduling tool on the market that does resource leveling. First it calculates the critical path, and then it applies the resource constraints to the schedule based on the options you’ve 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 don’t have analytical tools like Project push information into a Resource Commitment system like Outlook. Outlook at its core could be considered a personal commitment system. You make commitments in Outlook every day. 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 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 Project, which is, at its core, an analytical system. Moving activities from Project or Project Server into Outlook and retrieving the progress on them is one thing. What if all of someone’s Outlook tasks were 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 four-hour gap in my availability ripple through every task I have scheduled in the future? Should all tasks be pushed four 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 four 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'd have chaos. If we are to integrate a resource commitment or resource communication tool like Outlook with a resource capacity planning tool like Project or Project Server, we need to reconcile the philosophical differences between the two paradigms. When the link from Project Server to Outlook was designed, this made up part of the thinking. Outlook would be enabled to receive tasks from Project and to integrate those tasks into the Outlook calendar or task list. “Pushing” tasks from Outlook to Project Server was not permitted. 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 implementing 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 particularly 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 five percent 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 not found 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 Project Server, just like the Project team does at Microsoft. The “Microsoft EPM Solution” after all is a stack of technology. When you consider all the different aspects of Resource Management, then Windows SharePoint Services, Windows Workflow, Office SharePoint Server (for forms), SQL Server all become vectors that are essential to creating an environment that is tailored to what you need for your organization.

EPM – Centralized or Decentralized?

I’ve been a proponent of Enterprise Project Management since I first entered the project management

industry in the early 1980s. You’d think, then, that I would always vote on the side of centralized project

management, but that isn’t always the case. Let’s discuss for a moment just what we mean by

Enterprise Project Management.

EPM can mean a lot of different things to different people. I’ve already discussed in other articles in this

column how the focus of an EPM deployment might be document management for one organization

and integrated schedules for the next. Enterprise Project Management has at its core, however, the

notion that people must interact with each other in the project management exercise. That means that

the project manager and/or project management team don’t work completely independently. But does

that mean that the only way to achieve this “interaction” is to have a centralized project scheduling

system? Not necessarily.

For some organizations, the project management challenge might be an inability to produce summary,

enterprise-wide project management reports due to projects being all managed on an ad-hoc basis. In

this case, EPM might be achieved just by having project standards that are shared between all project

management personnel. That might best be achieved with a central pool of templates, training

materials, documents, and report standards that everyone can use. Perhaps a simple SharePoint site

would suffice.

For some organizations, the project management challenge might be ineffective personal schedules due

to a lack of communication between resources about what they’re working on and what their next focus

is. In this case, EPM might be achieved by improving team and inter-team communication. The tools

could be as simple as a shared calendar, Instant Messaging, or a shared portal where people could list

what their priorities are.

In some organizations, the project management challenge is just getting progress on the programming

development projects. If that’s the case, then the tools already present in a product like Visual Studio

Team Services might suffice. It’s quite common in programming projects to find that many tasks can be

completed in almost any order, so the rigors of Critical Path Scheduling might not even be appropriate

depending on the type of development being done.

I can remember a number of years ago working with the maintenance department of an airline. The

staff were allowed to choose their own schedules at the start of each month and if this wasn’t

coordinated (as was often the case), it was possible to arrive to manage a shift only to find out that no

one was working. Their project management challenge wasn’t “When will the work get complete?” it

was “is anyone coming to work?” In this case, EPM was achieved by implementing a shift scheduling

tool.

Even when we focus the EPM challenge to project schedules, it’s not immediately obvious that

deploying a centralized project management system is the only or the best answer. It’s worthwhile to

ask what interaction the project management personnel need to have with each other. If they must

collaborate on a regular basis to resolve resource conflicts, to see what other priorities in the

organization are coming up, or to see how the progress of one project will affect another, then looking

at a tool like Project Server makes perfect sense, but often I end up interacting with organizations that

have not even asked this question of themselves.

In some organizations we find a tiny number of schedulers and a large number of resources. Even in a

good-sized organization, this can be the structure depending on the industry and type of projects being

accomplished. Not that long ago I met with an organization that was sure they had picked the right

solution for their EPM challenge. They asked to me to articulate the solution but, as usual, I asked that

they first articulate their project management problem. By the time they were done describing their

environment on a white board it was apparent even to them that the solution they’d chosen wasn’t

going to solve their problem.

In this case, the problem was a lack of project progress that was being reported by a large pool of

subcontractors. The client determined that what they’d really need to do would be to impose a time

and billing type of timesheet on their subcontractors. The Program Director was discouraged. “We’ll

never be able to get that into the subcontractor contracts,” they said. Fortunately, a member of the

Finance Department was present. “You know,” that person replied, “a clause that requires them to fill

in the timesheet of our choice is already in the subcontractor contract.”

Problem solved.

The idea of walking through the problem before coming to the solution is one I talk about often around

here but it’s a tough one to adopt. Logical thinking would dictate that the order of determining an

automated solution would be:

1. Identify the problem

2. Define the solution

3. Determine whether to (and, if so, how to) automate the solution

Automated solution demonstrations on web sites, videos, and elsewhere make us forget that. We don’t

look for a solution, of course, unless we have some kind of problem, but the automated solutions look

and sound so compelling that we end up doing this:

1. Choose the automated solution

2. Make the problem deploying the solution

3. Solve that problem by defining how the automated tool can be applied to the solution

4. Try to remember what the original problem was

The new problem becomes deploying the solution for quite some time and then weeks, months, or even

a couple of years down the road someone from upper management asks when the original problem will

be solved and everyone looks at each other rather surprised. It was easy to forget about.

Over the years I’ve recommended all kinds of possible automated solutions. Oh, Project Server has been

one of the options of course, but I’ve also recommended a combination of Microsoft Project Pro and

SharePoint Server. I’ve recommended using a combination of Excel and Outlook. I’ve recommended

using third party timesheets with Project.

I even once recommended using a big white board. Honest. The organization was one I’d done business

with for years. The person in question was in a real-estate role and had to renew long term leases in

real estate. When I asked what the problem was, it was clearly a scheduling issue. The person had

missed a few deadlines that were important and was sure that an enterprise project management tool

would fix the problem. The organization had already asked for reports to be distributed to several

executives so that future deadlines wouldn’t be missed. “How many users would there be?” I asked.

“Just me,” he replied. “How many of these projects are there at a time?” I asked “Seven or eight,” he

replied. “And how many of these deadline milestones do you manage for each project “It’s very

complicated. There are about a half-dozen deadlines for each one,” he told me.

It was already clear to me that we shouldn’t be installing a big centralized EPM system for this poor

fellow.

“Why not just put up a big white board in your cubicle and use some colored markers for the different

milestones?” I asked. “You could use blue for the first one, green for the second, red for the last, etc.”

He took copious notes, fascinated by the concept. I left the firm knowing that I’d not sold any services

or product that day but that I’d left the person disappointed that he couldn’t deploy the system he’d

envisaged. On the way home my phone rang in the car. It was him. “Could you explain the different

colors for the white board?” he asked.

Figuring out what problems you’re trying to solve before you design the solution and before you choose

how to automate it doesn’t just save money. It can save an enormous amount of time spent working on

elements of the organization that didn’t have a problem that needed solving in the first place.

When the problems you’re trying to solve can be best solved with centralized enterprise project

management software, then nothing else will really do, but the focus you’ll have gained by articulating

the problem will help even there. Your deployment team can create success metrics that allow the

project to be declared a success when the problems have been resolved.

Centralize or decentralize? Enterprise Project Management can be achieved with either.

Creating an EPM Deployment Plan

“Can you help us install the EPM system and get it up and running in a few days?” is one of the most

common requests EPM deployment firms get. And regardless of the size of the organization, the short

answer, is unfortunately, “No.” The challenge isn’t technology; it’s a series of policy, process, procedure

and practice questions that have the potential to create far-reaching organizational change.

Let’s take a look at what an EPM deployment plan must include and how you can create your own. I’ve

identified the major points and even put in estimated times for how long each phase might take in a

mid-sized organization with several hundred EPM system users. Before you dismiss each time estimate

as too short or too long, think about what you would need to do in your particular organization in order

to accomplish that section. The durations are not work estimates, they are calendar estimates, so keep

in mind how long it takes to get certain kinds of people assembled for the kind of work you will need.

1. Establish the EPM System deployment team

If we have no project team then our project won’t go far. Several people will have to be assembled in

order to bring this project from the idea phase all the way to production. With an overview plan already

in mind, you will need to think about people who will be with the project as long as a couple of years.

Key steps in this first phase are:

Identify Key Stakeholders There’s often one key stakeholder before the project even starts. It’s usually someone at the executive level who is feeling the pain of not having this kind of system. That’s a great start but it won’t be nearly enough to bring such a project to fruition. Identifying the business owner of the system is critical to a successful EPM deployment and must be done almost immediately. The business owner will be the person who uses the benefits of the completed system and sees the value in going through what it will take to complete it. There may also be one or several executive sponsors. The executive sponsors might be management level staff who have some use for the ultimate results but they might also be people who will work on the project until its completion and then move on with little investment in the final operation of the EPM environment. You can live without an executive sponsor. You can’t live without a business owner.

Identify internal expertise resources

Having determined who the business owner and possibly the executive sponsors are, the project team should determine what internal expertise is needed and available to move the project forward. Often we’ll find a lack of expertise in a particular technology such as the current version of EPM software but that’s not the only kind of expertise we require. Internal

knowledge of the organization’s processes, practices, procedures, roles and responsibilities and where data can be located to drive the process will be essential.

Engage external expertise (if required)

It’s common to determine that there is a knowledge or skill gap in the project team to move from non-enterprise project management to enterprise project management. If that’s the case, then there’s no substitute for finding someone with know-how. To whatever degree the internal resources are not available, they’ll need to be engaged from the outside. These people might be engaged as part of a consulting or outsourcing contract or hired for long term use in the environment that they will help develop. Training for this kind of expertise from the inside is rarely successful. The most common challenge we see in this area is finding out that the internal resources have been given the responsibility but don’t have the knowledge or have only a limited knowledge. “I used EPM software once and now I’m being asked to deploy it,” is a cry we hear all too often.

The size of your team will depend on how wide a scope the project ultimately becomes. It is not

uncommon to find some people with the project for several months who are then replaced with others

as phases of the project change. The authority of the team and the support of management are also

critical to establish at this time.

Oh, and do I need to say it? Treat this project as a project! Amazing as it might sound, EPM

deployments are the most likely project in the organization to be deployed without any of the elements

you’d put into any other deployment plan (something about a shoemaker’s children going barefoot). So,

make a project schedule, a budget, a charter, allocate sufficient resources etc.

Time to accomplish this: Four weeks.

2. Identify Business Objectives

Ok, we’ve got the team together. Time to get it to work! We’ve got to now identify the scope of the

project, break that scope into phases if it’s big and then create a plan for the work.

Here’s what we’ll need to accomplish in this phase:

Executive and Stakeholder workshops

There’s no way to get around this. The whole purpose of creating an EPM environment is to better enable management and end users to make business decisions. So the relevant management personnel will need to invest some time at the beginning of the process to help identify what decisions will be made using the system. I’ve written about how to conduct such workshops in the past (See “How to be a Solution Buyer”) but how they’re done is less important than that they’re done. This is the opportunity for the deployment team to get two other very, very important things while they have management’s attention: First, the commitment of management to the process, the effort and the ultimate benefits. Second (and far more important), the managed expectations of management. The most common

management expectation is that this can be accomplished in a few days or a few short weeks. When they grasp the impact of what’s involved, management support may evaporate. Better to have that happen immediately than to get started on something that can’t possibly be delivered with insufficient time or resources. The results from these workshops (yes, it may take more than one) will be the business objectives that will make up the scope and ultimately determine the schedule.

Identify management role impact

Once the business objectives have been agreed to by management, there will have to be a session or two identifying the impact on the roles and responsibilities of management. A common example often appears with resource capacity planning. In high tech firms, resource capacity planning is almost always a management request of the EPM system, yet who will have to get the authority in that process to allocate resources, manage conflicts, and prioritize the work of people in different departments? You won’t be able to solve these issues at this point as you have no defined process, but identifying who in the executive suite will be affected is important here so that you’ll be able to circle back to include them in the process when the time comes.

Prioritize business objectives and create a Master Deployment Plan

It’s almost certain that the plan should break into phases. With virtually every EPM deployment, the desires of management on what benefits the EPM system should deliver are vast. The prioritization of which objectives to go for first is an essential element of success at this point. Get the top two or perhaps three objectives put into a phase and push everything else downstream. Each phase should deliver a working, production EPM environment that is valuable in its own right.

Establish milestones and metrics We’re project managers, aren’t we?! Let’s get some milestones into our project and commit to some measurable metrics. With any enterprise system deployment, making sure it’s staying on track is an important part of the process.

We should have enough information now to develop our overall schedule with detail for the first phase.

Time for this work: Four weeks

Phase 1

For each phase there will be some tasks that need to be repeated. Steps 3 to 9 are all part of one phase.

3. Inventory processes

Before we get anywhere close to the tools, we need to determine what processes will ultimately need to

be automated in this phase.

What processes exist and can be adopted?

We start with looking at what processes, practices, and procedures already exist in the organization for the business objectives identified in this phase and determine which can be adopted within the new EPM environment. There’s a two-sided benefit to finding existing processes that can be adapted with little or no work. First of all, they’re created already and known to the users. Secondly, adopting them makes a friend of the person who created them. They can now be named as a subject matter expert in that process and that eases deployment.

What processes must be designed

We never find all the processes, practices, and procedures we need, but we have to identify what’s missing. That can be harder than locating processes that exist already. You’re looking for what’s not there and that takes an experienced eye.

Process whiteboard workshops

For those processes that require work to be adapted or for processes that need to be created from scratch, you’ll need to get some workshop sessions with a white board underway. Walking through the process and all its implications is best done with the people who will live it once it’s done. Document everything.

Resolve impacted management roles

Remember when we identified which executives or managers might be implicated in the changes that would occur? Time to call them back. For any of the newly designed processes that affect roles, authority, hierarchy, or existing responsibilities, you’ll need to organize meetings to resolve them.

The final result of this is the draft of a process guide.

Time to accomplish the processes exercise: Four weeks.

4. Adopt, adapt, and design processes

Review, adapt, and accept designed processes Not everyone will have been a part of every process exercise that happened in the last set of tasks. So, getting the draft of the new process guide published to the stakeholders, managers, and affected parties is essential. It’s quite common for this guide to go through several reviews and even for additional workshops to be scheduled to resolve conflicts in processes.

The output of this is a completed and accepted process document. Don’t be fooled, the “accepted”

aspect may take several rounds and even require executive intervention from the highest level before

it’s complete but without an accepted process, there’s nothing to automate. The good news is, even if

the deployment process stopped here, this is already of great value. It is inevitable that those who work

through these processes internally see things about their organization that they had never considered.

They will be more effective as a result starting almost immediately.

Time to accomplish the completed process guide: Eight weeks

5. Evaluate and Select EPM Tools

Prepare “problem statement” documents for vendors

If you’ve read other articles I’ve done, you know that I believe strongly in giving potential vendors a description of your EPM problems and letting them tell you how they would solve them. After all, they say they’re in the solutions business? Great, have them design your solution. This is a little harder than making a spreadsheet of all the functions you would like, but it’s important.

Solicit vendor responses

Never do just one. You may already know who your preferred vendor is, but even if you think it’s the right one, get something to compare against. No two vendors will try to solve your problem the same way so be prepared to be surprised and keep an open mind.

Short list

Even if you’re looking at one product but several implementers, get down to who you’d like to meet in person.

Vendor and implementer presentations

Ahhh, demo day. There’s are many things of value to be had from looking at a demonstration but getting caught up in the flash of it isn’t one of them. Sales demonstrations are carefully orchestrated by all vendors. If you’re particularly excited over a view or a report or a dashboard, ask specifically, “How long would it take to develop that exact view?”

Tool selection and acquisition

Ok, time to make the big purchase. I know, you thought that was the starting point, back at the beginning of this article. Well, don’t worry. We’re finally here. Make your selection of the EPM system and get that purchase order on its way!

The end result of this phase is a shiny new EPM product sitting on your desk.

Time to accomplish this phase: Eight weeks.

6. Automation Design and configure

Apply the process design document to the selected EPM tool

Now that we know what the tool is we can start creating system design documents that start with our process document and end up in functional specifications. We’ll probably want a Development instance of our new EPM system installed so we can test or verify certain design criteria. For the first time, a system expert in the configuration of the actual system is required on board.

Design and implement standards

There are numerous standards that will have to be established. Each and every one of those standards carries implications in the system architecture and design. The calendar for example is often overlooked. Will we have one calendar or many? Will we have resource calendars? Who will have the authority to change them? Do we know the effects on the schedule and progress data of changing a resource calendar ? And so on … Here are some of the elements of our EPM system that we will need standards for: Calendars Naming conventions Resource hierarchy Resource load standards for project

and non-project work Rates and costing standards Roles and responsibilities

Approval structures Project and task hierarchies WBS and other coding structures Document management Communication templates Project templates

We’re also going to need some other design and even possible coding for elements that came out of our Phase One business objectives. Some of the elements that might have to be considered are: Design and implement custom

coding Design and implement

dashboarding Design and create links to external

systems Design and create workflow Design and implement reporting Design and create EPM tool

training Review design with all affected

parties

The result is an EPM tool that is ready to be taken out for a ride. It should have all the configuration

required to move into a working environment.

Time required for this phase can vary greatly depending on how much custom work was required but

we’ll say twelve weeks given we’ve restricted ourselves to the first phase.

7. Pilot EPM Tool

Now that we have our system ready to go, we must identify the pilot group and get them working on it.

Phase 1 install / configure / migrate data

We’ll need to install the newly configured system in a pilot instance (not the development instance. We’ll continue to use that for future phases and as a support and training system). We’ll also need to update the configuration to match our development instance and migrate the pilot projects from whatever they’re in now into our new system.

Training

Training is the poor stepchild of project deployments. It’s often forgotten in a deployment plan. Make sure our pilot personnel get the training they need to use the system properly.

Run active projects

Now, have those pilot projects be managed based on the processes, practices, procedures and automation that you’ve spent so much time defining. The pilot needs to have a schedule itself that is often oriented around how long these projects will last.

Lessons learned and document

Once the pilot project is complete, it’s time to reassemble and see how what was created solved the challenges that were set for it. If there are adjustments, corrections, or basic changes to make, now is the time.

Time for a complete pilot project and review: Twelve weeks.

8. Roll out Phase 1 into production

Go-live

It’s time. Roll out the use of the new system to the appropriate users and migrate the appropriate data. Don’t forget training, support, and follow up as the system goes live

Time to rollout is highly dependent on the number of total users: Four weeks.

9. Review and Adapt Master Deployment Plan

Review and adjust master plan in preparation for next phase

The master plan probably hasn’t been looked at in months. Time to dust it off and see what was originally planned for Phase Two. It’s inevitable that the eyes that look at the next phase will see things differently. After all, they now have all the experience of the first phase.

Time to complete this phase: Two weeks.

10. Phase 2 – do steps 3 through 9 again

We’ve only completed phase one and as you look at future phases you’ll need to rework steps 3 through

9 (with the exception of step 5). Remember that each phase should result in a working EPM production

that leaves the organization more effective than it was before.

Have you been counting the durations for each of the steps for the first phase? It adds up to 58 weeks.

Here’s a schedule of the summary steps defined above:

Now, every organization is different. There are many factors that affect the total duration of a project.

The most significant of these is the extent to which existing enterprise project management processes

are mature. Next is the size of the organization and its complexity. It is obviously simpler to deploy an

EPM system into an organization that is all located in one building than it is for an organization that is

spread across numerous divisions, offices, cities and even countries.

In each deployment the schedule will look different and not always shorter. There is virtually always

pressure to make a schedule that can be accomplished in days or even weeks, but it’s vital that more

than just the installation of EPM software be considered in order to deliver a successful deployment.