Anda di halaman 1dari 79

EPM ROADMAP MICROSOFT PROJECT

Strategy

People

EPM
Technology

Process

AUTHOR RICK KHOSLA

Table of Contents
INTRODUCTION WHAT IS ENTERPRISE PROJECT MANAGEMENT?
Basic Project Management Enterprise Project Management Project Portfolio Management (PPM) Resource Management Reporting Analysis Budgeting and Cost management Timesheets Communication and Collaboration Integration with External Applications Workflow Business Intelligence

6 6
7 7 7 7 7 7 7 8 8 8 8

THE PROJECT MANAGEMENT MATURITY MODEL EPM DEPLOYMENT APPROACHES


Big Bang The Instant Bang The Phased Approach

8 9
9 10 11

GETTING STARTED WITH YOUR EPM DEPLOYMENT STRATEGY


1. The Project Management Office 2. Executive Sponsorship 3. Were project managers we dont need project management! 4. Set goals

12
12 13 13 13

GETTING STARTED
Envision Whos who? Make a Project Plan

13
13 14 14

CONCLUSION DETERMINE PROJECT MANAGEMENT REQUIREMENTS (PROJECT SERVER 2010)

14 15

DIFFERENT STROKES FOR DIFFERENT FOLKS FACTORS IN CHOOSING YOUR PROJECT RESOLUTION
How long is the project? How many resources are involved? How are resources managed or sub-divided? How quickly can you gather data and how much effort does that take? How often will we update?

28 31
31 32 32 33 34

REVIEWING YOUR WORK


Is it too much? Should we do it at all? A nimble no, an Agile project Wrapping up

34
35 35 35 36

WIZARD OF OZ SYNDROME MEASURE EVERYTHING HALF-BAKED PLANS BEST BEFORE DATES DATA PEDIGREE ARE WE LOOKING AT THE WHOLE PICTURE? GAMERS GALORE
Change the process No carrot, just stick Checks and balances

38 38 39 40 41 42 43
44 44 44

SOME BASIC RULES


Indicators must trace back to source data Every indicator needs an action The data must be complete or show that its not The display must show its timeliness Check data quality in an ongoing fashion 1 Planning

44
44 44 44 44 45 52

2 Tracking 3 Resource Management 4 Cost Management 5 Advanced

52 53 53 53

CREATING AN EPM DEPLOYMENT PLAN 1. ESTABLISH THE EPM SYSTEM DEPLOYMENT TEAM
Identify Key Stakeholders Identify internal expertise resources Engage external expertise (if required)

71 71
71 71 72

2. IDENTIFY BUSINESS OBJECTIVES


Executive and Stakeholder workshops Identify management role impact Prioritize business objectives and create a Master Deployment Plan Establish milestones and metrics

72
72 73 73 73

PHASE 1 3. INVENTORY PROCESSES


What processes exist and can be adopted? What processes must be designed Process whiteboard workshops Resolve impacted management roles

73 73
74 74 74 74

4. ADOPT, ADAPT, AND DESIGN PROCESSES


Review, adapt, and accept designed processes

74
74

5. EVALUATE AND SELECT EPM TOOLS


Prepare problem statement documents for vendors Solicit vendor responses Short list Vendor and implementer presentations Tool selection and acquisition

75
75 75 75 75 75

6. AUTOMATION DESIGN AND CONFIGURE


Apply the process design document to the selected EPM tool Design and implement standards

76
76 76

7. PILOT EPM TOOL


Phase 1 install / configure / migrate data Training Run active projects Lessons learned and document

77
77 77 77 77

8. ROLL OUT PHASE 1 INTO PRODUCTION


Go-live

77
77

9. REVIEW AND ADAPT MASTER DEPLOYMENT PLAN


Review and adjust master plan in preparation for next phase

78
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 hasnt 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? Thats a short question with a potentially long answer. In the early stages of an EPM deployment we do an envisioning workshop with the clients senior management. One slide that I always use looks like this:

What is EPM from your perspective? Ill 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 wouldnt 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)


Its 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. Wed 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 weve 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 were talking about reports, well 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, wed be so far ahead of where we are now, wed call that an EPM success, someone often says.

Communication and Collaboration


Its 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?

Strategy

Integration with External Applications


Weve got a big ERP/Finance system which is great except that we dont 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!

People

Technology

EP M

Proces s

Workflow
We envisage a system that tracks not just tasks but procedures in an automated fashion. Wed 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. Wed like to do the same with all our project documents. In fact, wed 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


Were working on improving our maturity level as measured by the Project Management Maturity Model. So, whats the right answer? Theyre all right. In fact, its 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 well

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 isnt 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 were 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


Lets 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 Lets do it all! The idea is that well 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, well 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, theres a better chance than with other types of approaches that the end result will be closer to the original intent. After all, the team doesnt rest until theyve 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 doesnt 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, were 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 theyve been unable to entice the rest of the organization to work together.

The Phased Approach


Weve 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. Its 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. Ive 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 theyll say, Oh, we cant remove that, we get this out of it every week. If were successful creating that kind of deployment, well be able to build on it in the months to come. If were not, the project and the deployment is still very much at risk.

Getting started with your EPM Deployment strategy


If Ive made you think twice about doing an EPM deployment, thats 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? Lets start with a few prerequisites.

1. The Project Management Office


If your intention is to deploy an enterprise project management environment, theres 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 theres 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 dont have such an organization (even if its one person) then youll 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 theyll 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 theyll try to do the deployment themselves in order to get that support. Its the Field of Dreams Build it and they will come approach and its 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. Were project managers we dont 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 its amazing how many EPM deployment projects dont, 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 shoemakers 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 youre 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, youll find its most useful here. Having someone who has been involved in several other EPM deployments is the key to success. Were not just talking about someone who has

been a user of an EPM system but someone who has worked through some of the issues weve 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.

Whos who?
One of the things youll need to decide on early is, who is the enterprise? Ive 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. Its a variant on the Field of Dreams approach and it makes for a solution thats 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 theyre 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. Theyre 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, its 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. Youll 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. Its not enough to make a system that works for senior management but doesnt work for the people who have to manage it. Or, a system that works for the project managers but doesnt 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 youre designing a deployment that follows a phased approach and uses the basic project management methodology you already have for other projects, youve 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 Master projects Project workspaces Risk management Issues management Document management Resource management Task management

Medium High Low Medium High Medium Medium 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. Its not a lack of definitions of these three concepts that causes confusion, its their similarity. Those of us who have worked in IT for many years tend to see things from a technical perspective and sometimes it doesnt serve us well. If we look at data from Portfolio Management, Project Management, and Task Management, it might look very similar. Ive 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. Lets take these three concepts one at a time. Its 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 its done in ones head. Its 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 were 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? Its 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 doesnt match the estimate of the portfolio selection process? If the estimate is less, theres probably no issue, but if the work cant 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 isnt 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 were working at an individual or a small team member level. We dont see the tasks in context. We see those things weve committed to or perhaps those things weve 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 youre 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 Theres a saying, If it looks like a duck and quacks like a duck, it must be a duck. Thats true for ducks, but it isnt always true for task-based data. Lets 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. Im 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 were giving technical advice: Dont 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 theyve 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. Thats 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 wont 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 doesnt 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-torecord 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 wouldnt 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 wasnt 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 managers 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, topdown. 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 doesnt have direct benefit by being fully integrated from another level, then integration is not the best play. Its 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 individuals 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, todays 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 byhow many tasks you should have in your project schedule and how long each task should be? On a regular basis Im 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. Ive 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. Ive 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. Ive 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, whats 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. Lets 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. Well 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. Its 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. Lets leave the

emergency type aside for a moment; its 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 its 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 thats 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. Its 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 doesnt.

Factors in choosing your project resolution


With these three distinctions, its 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 its a software project so tasks can only be 1-10 days long, (and please, dont do that) what characteristics of the project tell us what level of resolution to choose? Lets take a look at a few obvious ones:

How long is the project?


Lets 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. Its 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 ones mind at one time. Personally I go with no more than 8 items per WBS element and thats 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 cant. Its 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 subdivide 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 its a good indication that the task youre thinking of is too small to be worth managing. If thats 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 its

worthwhile to think about even if for a moment. If its 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.

Lets apply a reality check to what Ive just talked about. In a two-year EPC project, if a one-week task is a day late, its almost certainly not worth taking action over. In a six-month Software project, a oneweek 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, its 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, its 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-contractors 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 purposebuilt. 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 wont 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 youre 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 subcontractors, 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. b. Think about how you will collect your data. 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.

Ive 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? Ill 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, well 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-monthlong 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 todays 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-oninvestment 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 its much less common. Agile was designed for a corporate development environment where we are creating software for inhouse 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, theres 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
Theres no doubt about it. Dashboards are all the rage. Whether its 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? Thats 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, theres 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 wasnt 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, lets 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, its 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 youre designing a dashboard. For every indicator, there has to be a trail back to some source and it is best if its documented. If the dashboard is driven by Bob filling in a spreadsheet with how he feels about the projects, just have him tell you. Itll 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. Its easy to get caught up in the technology of dashboarding and theres 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, youve got thermometers filling up with red or tachometers revving into the red-zone or arrows in different colors. Dont 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 whos making an executive dashboard gets so caught up in their ability to make an indicator that they dont stop to look and see if they should be making it at all. Its not always "how do you do it?"; sometimes its "should you do it?" Once theres so many visually stimulating indicators on the page that it looks like the dashboard of the space shuttle, you know youre either going to need years of training like an astronaut or youre going to need to make life simpler. Heres 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 its 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 wouldnt eat a cake that only had half the ingredients, especially if you didnt know which half were missing. On a dashboard, how do you know you have all the data? Lets take an example of looking at resource capacity reporting. The resource traffic light has become red for IT (isnt 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 doesnt 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 youre like me you reach into the refrigerator and grab the closest cheese to you, but shouldnt you be checking the "best before" dates? While were 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?

Its not uncommon to do an audit of a dashboard indicator only to find that the data that originates the indicator hasnt been updated in a long time. Its 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 havent changed (unlikely in most project environments) or that the data hasnt 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?" Theres 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 were 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?


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

Lets imagine that IT has red lights for both the schedule and cost indicators on a particular year-long project because its June and both indicators are off by more than 20%!

The Chief Financial officer has looked at the detailed results already and hes quite upset. The January June actuals show the tale:

($,000s) Budget

Jan 80

Feb Mar 100 120

Apr May 120 120 140 140 20 80 20 100

Jun 120 140 20 120

Actual 100 120 140 Variance Cum Variance 20 20 20 40 20 60

So far the project is already $120,000 over budget and its 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 Budget 80

Feb Mar Apr May 100 120 120 120 140 140 20 80 20 100

Jun

Jul

Aug

Sep 120 80

Oct 120 40

Nov 100 0

Dec 80

Total 1,320

120 120 120 140 120 100 20 0

Actual 100 120 140 Variance 20 Cum Variance 20 20 40 20 60

0 1,120 (200)

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

120 120 100

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 theyre 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 thats a huge step. But, be advised, as soon as dashboardtype indicators are made available, people will use them to their own advantage. Its completely understandable that people will game the process if they can by skewing data under their control to have them not look bad. Theres 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 its not always possible to find such checks and balances within the data, so vigilance is always a good thing.

Some basic rules


Ok, lets wrap up some of what weve 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 weve discussed above:

Indicators must trace back to source data


Make sure that indicators arent 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 its not


Make sure that its is clear from the display that the data is either complete or incomplete so that inappropriate decisions arent 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 cant 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 isnt 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-users PC, and care of the system was always a local concept. These days thats 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 thats 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, lets 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 cant 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? Its 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 Ive 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 didnt 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 its not surprising to find that the organizations 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 dont 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 clients 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 organizations standard database servers, the SQL Server version on which theyd installed the system was on an end-

users 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 its 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 isnt 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. Thats 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 didnt go back in as cleanly as wed suspected it would and we had to update our backup procedures. Staging/Production All the worlds 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 thats 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 thats 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 havent 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. Its 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 its 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, its 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 its rolled out to production. Document, document, document The people who were there when Project Server was selected and deployed wont be in those roles forever. In fact, if they did a great job, theyll 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 Its 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. Theres a whole conversation to be had about how organizations become more effective and Im 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, its very common to find that the desire of organization is to reap the benefits of every single element of the new system theyve just had demonstrated by the vendor. The client sees reports and screens and workflows and functions that theyve 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 theyve 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. Its a natural progression. As the organizations 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 isnt a good plan. Its 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. Lets talk about the five basic areas to start with, and Ill cover some of the new shifts that weve seen over the last few years nearer the end of this article.

5. Advanced 4. Costs

3. Resources
2. Schedule Tracking 1. Schedule Planning
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 teams 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 Im 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, theyll 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. Theyre planning in their project management system, and then theyre working the plan by updating it regularly and even giving useful reports to management.

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 Ive 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
Ill put a fifth area here for Advanced subjects for what might be a wide range of topics that I havent put in the other categories so far. Its not that theyre 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, Ill put risk analysis, document management, and automated workflows in here. There are also advanced areas in each of the other four areas Ive discussed so far. Each of the elements Ive discussed so far could be extended further and often is as the organizations 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).

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

Most organizations progress with all five of the basic elements from the left side of the graphic above in the order that Ive 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. Its 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! Its 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 Ive not done so here because from this point the most common progression is less clear. Each

organizations 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 Ive 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. Its now not at all uncommon to find that the project team extends not just beyond the buildings walls but well outside the organization itself to include sub-contractors, prime-contractors and even the client. Subcontractors 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:

5. Planning and Resources 4. Timesheets 3. Issue Management 2. Document Management 1. Communications plan
The first element in these organizations is to create a communications plan, and thats 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

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 managementone document of which might well be a project schedule. Its 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. Dont get a handle on communications, and the loss of efficiency might well be serious. From document management, its 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 isnt 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 havent been doing project scheduling so far but it wont 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. Theres no right way to advance in your use of your project management system, nor is there a wrong way. As Ive 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. Im 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 its 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. Youd think that would mean wed 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 Lets 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. Well come back to resource leveling a little later. Critical Chain Planning Its 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 schedules delivery. It is, perhaps, what CPM should have been from the beginning, and when its 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 organizations decision makers: Can I meet the commitments Ive 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 Im 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 Im 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 theres no work to be done, theres 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 youre 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. nonproject 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 youre over-allocated and present the challenge of dealing with the over-allocation. Should projects be prioritized so that some get the resources and some dont? Should some tasks be prioritized so that some get the resources and some dont? 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 counteroffer 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; its determining what has actually happened. If you could just tell me what my people are actually doing with their time wed 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, thats 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. Its 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 theyve requested and the commitments theyve made. A resource might say Ill finish that by Friday. Thats a commitment; a promise. It might be a perfect match for the expected finish date in our schedule, and it might not. Its a commitment and thats 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 dont 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 SubContracting could be addressed with functionality from Office SharePoint Server.

The Challenge You may note that Ive not talked about Resource Capacity Planning, and its not because its not possible. This is typically the most requested aspect of an EPM deployment, but its one of the hardest to actually deliver. Theres a fundamental challenge when we try to apply a resource leveling algorithm to a highly skilled group of resources. In order to understand it, its 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. Lets take this example:

Ive got a simple project here in Project Professional 2007. Ive 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, Ive 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 lets level the project using Projects Resource Leveling algorithm:

Again, things are perfect. Chriss 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. Alls well it seems until we add another resource to the calculation. Lets go back to our first situation and add a couple of additional tasks to the project but assign them to someone else:

Now Ive 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 weve added three tasks for John who will start at the same time. Johns tasks, though, are already resource leveled because there is some sequence to them. If were looking just at Johns 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 Chriss time just the way it did the first time and Chriss work is continuous from week one to week two. John, however, is going to have a full weeks gap in his work as he waits

for Chris to complete his second task. Its unlikely that well 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 Chriss supervisor(s) to manually manage how they should schedule their time. Were 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 proj ect thats affected or more than one person put on each task. This isnt 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 youve 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 dont 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 youll be at an appointment next week at 2pm. (That someone might be yourself.) You promise someone youll 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 were 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 someones Outlook tasks wer e 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, Im only one person. What happens when everyones 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 youve made it this far, then you may be hoping Ive got some advice on how to create resource management, and I do have a few suggestions. First of all, its worthwhile to talk about what aspects of resource management apply to your organization and which you can take advantage of quickly. Its quite common to find that some aspects of resource management will be a bigger challenge to implement than others. Im 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 youre 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 thats 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 hasnt considered all the implications, it isnt uncommon to imagine a system where analysis is done somewhere centrally and it not only magically reconciles every individuals 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, Ive got an idea for you thats 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. Its 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?


Ive been a proponent of Enterprise Project Management since I first entered the project management industry in the early 1980s. Youd think, then, that I would always vote on the side of centralized project management, but that isnt always the case. Lets discuss for a moment just what we mean by Enterprise Project Management. EPM can mean a lot of different things to different people. Ive 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 dont 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 theyre 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 thats the case, then the tools already present in a product like Visual Studio Team Services might suffice. Its 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 wasnt 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 wasnt 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, its not immediately obvious that deploying a centralized project management system is the only or the best answer. Its 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 theyd chosen wasnt 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 theyd really need to do would be to impose a time and billing type of timesheet on their subcontractors. The Program Director was discouraged. Well 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 its 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 dont 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. 2. 3. 4. Choose the automated solution Make the problem deploying the solution Solve that problem by defining how the automated tool can be applied to the solution 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 Ive recommended all kinds of possible automated solutions. Oh, Project Server has been one of the options of course, but Ive also recommended a combination of Microsoft Project Pro and

SharePoint Server. Ive recommended using a combination of Excel and Outlook. Ive recommended using third party timesheets with Project. I even once recommended using a big white board. Honest. The organization was one Id 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 wouldnt 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 Its very complicated. There are about a half-dozen deadlines for each one, he told me. It was already clear to me that we shouldnt 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 Id not sold any services or product that day but that Id left the person disappointed that he couldnt deploy the system hed 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 youre trying to solve before you design the solution and before you choose how to automate it doesnt just save money. It can save an enormous amount of time spent working on elements of the organization that didnt have a problem that needed solving in the first place. When the problems youre trying to solve can be best solved with centralized enterprise project management software, then nothing else will really do, but the focus youll 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 isnt technology; its a series of policy, process, procedure and practice questions that have the potential to create far-reaching organizational change.

Lets take a look at what an EPM deployment plan must include and how you can create your own. Ive 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 wont 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


Theres often one key stakeholder before the project even starts. Its usually someone at the executive level who is feeling the pain of not having this kind of system. Thats a great start but it wont 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 cant 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 well find a lack of expertise in a particular technology such as the current version of EPM software but thats not the only kind of expertise we require. Internal

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

Engage external expertise (if required)


Its 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 thats the case, then theres no substitute for finding someone with know-how. To whatever degree the internal resources are not available, theyll 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 dont have the knowledge or have only a limited knowledge. I used EPM software once and now Im 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 youd put into any other deployment plan (something about a shoemakers 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, weve got the team together. Time to get it to work! Weve got to now identify the scope of the project, break that scope into phases if its big and then create a plan for the work. Heres what well need to accomplish in this phase:

Executive and Stakeholder workshops


Theres 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. Ive written about how to conduct such workshops in the past (See How to be a Solution Buyer) but how theyre done is less important than that theyre done. This is the opportunity for the deployment team to get two other very, very important things while they have managements 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 whats involved, management support may evaporate. Better to have that happen immediately than to get started on something that cant 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 wont 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 youll be able to circle back to include them in the process when the time comes.

Prioritize business objectives and create a Master Deployment Plan


Its 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


Were project managers, arent we?! Lets get some milestones into our project and commit to some measurable metrics. With any enterprise system deployment, making sure its 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. Theres a two-sided benefit to finding existing processes that can be adapted with little or no work. First of all, theyre 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 whats missing. That can be harder than locating processes that exist already. Youre looking for whats 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, youll 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 its 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, youll 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. Its 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. Dont be fooled, the accepted aspect may take several rounds and even require executive intervention from the highest level before its complete but without an accepted process, theres 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 youve read other articles Ive 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 theyre 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 its important.

Solicit vendor responses


Never do just one. You may already know who your preferred vendor is, but even if you think its 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 youre looking at one product but several implementers, get down to who youd like to meet in person.

Vendor and implementer presentations


Ahhh, demo day. Theres are many things of value to be had from looking at a demonstration but getting caught up in the flash of it isnt one of them. Sales demonstrations are carefully orchestrated by all vendors. If youre 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, dont worry. Were 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. Well 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 Approval structures Naming conventions Project and task hierarchies Resource hierarchy WBS and other coding structures Resource load standards for project Document management and non-project work Communication templates Rates and costing standards Project templates Roles and responsibilities Were 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 well say twelve weeks given weve 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


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

Training
Training is the poor stepchild of project deployments. Its 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 youve 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, its 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
Its time. Roll out the use of the new system to the appropriate users and migrate the appropriate data. Dont 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 hasnt been looked at in months. Time to dust it off and see what was originally planned for Phase Two. Its 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


Weve only completed phase one and as you look at future phases youll 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.

Heres 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 its vital that more than just the installation of EPM software be considered in order to deliver a successful deployment.