STEP 3

Planning and Implementing the EPMS

Step 3 Introduction

3.1 Initializing the Project

3.2 Developing the Scope of Work

3.3 Architecture and Design

3.4 Scheduling the Project

3.5 Budgeting the Project

3.6 Determining Quality Expectations

3.7 Risk Analysis

3.8 Organizing the Project

3.9 Implementation Steps

Step 3 Summary

Introduction to Step 3

Now that we’ve armed ourselves with the right information to create the EPMS, prepared the organization to accept it, and designed it, we are finally ready to create the project plan to actually manage the work of developing and implementing it.

This chapter outlines a basic project management approach and then goes into details on how to apply project management to a complex information technology (IT) infrastructure project. If you are already experienced in IT project management, feel free to skip over the more basic portions. If you are a senior manager who is in charge of managing such an effort or a project manager with experience in other fields, go through each section to understand the steps involved.

As stated earlier, as a project manager, you are always being measured against the schedule and budget you create at the beginning of the project. If you are six months into a 12- month project and you’re two months behind schedule, is it because you’re doing a bad job managing the project? Because something unexpected happened? Or, because the plan was bad to start with? The more thoroughly you plan out the project, the less likely it is to be late or over budget.

In this chapter, we’re going to walk through the development of the project plan to design and implemented the EPMS, starting with developing the scope of work and going through the detailed architecture, scheduling, budgeting, and other needed project management steps.

Before we start, it is important to determine how the EPMS will be implemented. Will it start with a pilot program in one small part of the organization and then expand from there? Will it be rolled out in a big bang to the whole organization? Will some other approach be used? It makes a difference in how the development project is planned.

The approach we recommend is to start small and then evolve the EPMS as you learn more, as people get used to it, and as the acceptance among management grows. This is similar to the recommended approach for Project Management Office (PMO) implementation. In fact, we will go through some document PMO implementations to give you an idea of various approaches.

The first step here, if you have not already done it, is to find out what projects already exist.

An organization of any complexity has many departments that do not fully coordinate with each other. Each department determines what is most helpful to it and develops projects to support its goals. The result is that there is often similar, even identical, projects going on in different departments. A major benefit of the EPMS is that these wasteful efforts will be identified and coordinated.

When doing this initial survey, the team members should:

The results will identify the requirements for the new system and will guide the team on how to approach the project plan.

There is a complexity here, which we often see in organizations that have grown through mergers and acquisitions. The companies they purchase may already have a portfolio management system, or a PMO, in place. Trying to get everyone on to a single, unified platform will result in failure. It will not fail for technical reasons, but for political reasons. No organization will be willing to give up a system it is used to without a fight. If faced with this situation, it is easier to have the IT department in the owning organization create software, which could take the outputs of each independent system and combine them into something the decision makers can use to effectively manage the projects in the overall organization. That approach is beyond the scheme of this book.

A Note on Commercial Tools

According to research by the Center for Business Practices,¹ most organizations have developed their project portfolio management process in-house (87.0 percent). Only 13.2 percent of organizations have implemented a project portfolio management software tool.

If the decision has been made to purchase a commercially available tool rather than develop one in-house, there are many other activities regarding defining requirements and procurement processes that must be performed. Even the best commercial tools will generally satisfy only 80 percent of your criteria plan on developing internal workarounds for the 20 percent that the tool cannot provide. Hint: DON’T trust the software vendor salespeople to tell you the tool you select will cover everything you need. The tools are thorough, but probably do not operate in the way that is best for your organization.

This is an important sequence. You must determine yourself first what your organization needs before you start looking at commercial tools. Identify your current requirements for an EPMS and any future growth needs you can anticipate. Remember that once you purchase a tool, you’re locked into it for years.

Pre-made tools have their own business processes built-in. While this can be advantageous, it also means that you will have a more difficult time convincing people to use the tool because it requires changing how they work today. The OCM effort need to convince employees and managers to actually use the new system will be much larger than it would be for an in-house tool that takes into account how people already work.

Implementing a commercial tool requires that you consider the tools abilities and limitations as well as your organizations when it comes time to put it into the production system. Many times, upper management expects immediate results from an expensive tool without understanding that the data you fed into the tool was the same poor data you had before the tool. Management is trying to make decisions with data that is no better than it was before.

Because of the extensive work required to configure a tool to your organization and input all the existing data, tools often get a reputation among the project managers as more overhead and bureaucracy, leading to even more resistance.

Which tool should you buy? The academic answer is “It depends.” It depends on your organization’s needs and expectations, and how willing people are to change how they work.

The most capable tools change year by year as vendors try and catch up with their competition. Organizations such as Gartner and Forrester review tools annually and release reports on the ones that provide the most capabilities. If you go through several years of reports, you will see that different vendors leapfrog from one year to the next.

Socio-technical systems are combinations of people, processes, and technology (PPT) to accomplish goals. When everything comes together just right, the end result is far more effective and efficient than if the different parts of the end system are done independent of each other and without consideration for the other parts.

If one part of the PPT triad is ineffective, the results are poor, and the other areas must compensate for it. If the people in the portfolio management area don’t have the right tools or processes, the entire EPMS will be inefficient and not deliver the results expected. If the people themselves are inexperienced or untrained in project and portfolio management, the results will be the same—the EPMS will not deliver what was expected or needed.

In order to ensure that everything comes together just right, the EPMS must be designed for the right combination of people, processes, and technology and then thoroughly planned out just as any other project would be.

3.1 Initializing the Project

If you develop the EPMS internally, it should be compatible with the organization’s existing project planning/reporting application (if one exists). This way managers and employees only have to input data once for new project ideas and it can be propagated upward into the EPMS. Of course, the systems must be able to access the same data and pull up reports at various levels. It also means that all project managers must be using the same or compatible project management tools configured to the same status metrics.

When you develop a project plan for the EPMS implementation, it’s just like a project plan for any other project you manage. You will write a project management plan that may include how to manage areas such as:

Does a project manager need to do all of these in detail for every project? Absolutely not. You, the project manager, decide what to do, and to what extent, to make this project as successful as possible. How long will it take to write and get approved an overall management plan? Longer than you would think due to the need for review and rewrite cycles. We will offer a proposed schedule later.

For these areas, it is expected by upper management that the project management plans will be written to ensure that you have thought through exactly how you’re going to manage the project. For a project the size and effort of an EPMS implementation, you don’t need to write a separate management plan for each one of these areas unless your own internal project management processes require it. It should be adequate to write a single project management document that covers all of these areas. This top-level management plan would have a section for each of the previously mentioned areas. If some of the work can be done by other parts of the organization, such as quality management or procurement, just reference those areas rather than recreating a plan for each.

There are multiple consultants who have come up with critical success factors (CSFs) for successful EPM implementations. They all say pretty much the same things. Gartner² found seven CSFs for a portfolio management system that are common to many such recommendations:

All of these should be taken into account when planning out the implementation process.

In order to ensure that all projects, even existing ones, strongly support strategy, we will put all projects through the filtering process, proposed as well as existing. The advantages are that it will kill projects that no longer make sense and any duplicative projects that are wasting resources. The disadvantage is that when people learn that the projects they’re working on are being re-examined, they may become less productive until they learn whether their project has been approved or not. Why work hard on something that might get canceled?

3.1.1 The Project Charter

Before you even start writing the management plan, you will need to write a project charter and get it approved. If you were involved in developing the business case that we discussed earlier, that should be sufficient to justify the project. You should consider simplifying it so that it provides useful material for discussion during the project’s kickoff meeting. There is no need to swamp people with details only the decision makers need.

If there was no business case, you will need to develop the project charter. This is typically a relatively high-level document that states the following:

The goal of the charter is to get the primary organizations that will be involved in the project to understand what the goals of the project are, its overall approach, their own roles and responsibilities, and rough-guess schedule, budget, and risks. Once everyone agrees on it, the charter is signed and approved.

The project charter documents the project at a summary level and gives you the authority to spend the company’s time and money, and use its resources, to do the project.

3.1.2 The Kickoff Meeting

The kickoff meeting is a gathering of the primary players in the EPMS development. Often thought of as being a waste of time, it is, in fact, a critically important meeting for the project manager. Yes, by now, everyone involved has heard of your project and understands the goals, but that’s not the point. The meeting is important to you because this is where you take charge of the project and start making decisions. This is where you show your leadership capabilities and get the primary participants to agree on the way you will manage the project.

What should be done during a kickoff meeting? For starters, it should be scheduled for at least a day. This is a significant project and needs a strong start. This is not a meeting you can do in 2 to 4 hours. Plan on scheduling several sessions if needed.

Secondly, get a dedicated note taker to capture the major points of the discussion and decisions made as well as to capture action items or things to put into the parking lot for later resolution. You’re running the meeting, if you’re taking notes at the same time, you might miss something important. An outside facilitator could help the meeting move more efficiently.

What should be done during the meeting?

After the meeting is over, complete any action items captured during the meeting. Write up the meeting minutes and send them to everyone involved. Ask for their feedback to make sure the minutes accurately capture what was discussed and agreed-to. These minutes will form a baseline document that you can use in the future to remind management what had been agreed-to at the beginning of the project.

3.2 Developing the Scope of Work

3.2.1 Scope of an EPMS Project

We talked about the business requirements in the previous section, but now let us look at them in more detail specifically as they apply to our EPMS project. As in any project, the first big step is to define your scope of work. This includes both the final scope of the product, in our case, the EPMS, but also the scope of work needed to develop and implement it.

The product scope is defined by the requirements. The project scope includes the size of the team, the schedule, the budget, and all the work needed to be done in order to give the organization a successful enterprise portfolio management system. We can help you with defining the product scope, but identifying all of the details that will determine the project scope is situational to your specific environment.

In order to understand what the end result will look like, we have to understand what it is expected to do. This is the process of gathering management’s needs and expectations. These are the requirements that we will build to. We discussed the process for gathering those in detail in the last chapter.

Now that we understand what requirements are, we can start by asking what are the functional requirements for an enterprise-level portfolio management system? Remember: the functional requirements are the things that the system should be able to do, as contrasted with how well it does them, how easy it is to use, or other constraints such as privacy and data security.

Certainly, a major functional requirement is that the system should be able to accept the requests for new projects. This requirement will be implemented by developing a process that captures each new project request. Once the request for a project is created, further processes will provide more details, prioritize the request, identify the risks in doing it (and in not doing it), and present it to the decision makers to be approved or not.

Another major functional requirement is that the system should track the status of each project in work. This implies a common set of metrics that all projects use so that the projects can be measured against management’s acceptability parameters (red, yellow, green), against the business case for the project, and against each other. This can also be done if the organization is using an enterprisewide project planning tool managed by the PMO.

A third functional requirement is that the EPMS should identify the level of utilization of each resource used by all the projects. This prevents resource conflicts and allows the resources to be scheduled in the most efficient manner possible. This is also a function that can be done by the PMO if the proper planning tool is used.

The most basic functional requirement is that the system delivers a prioritized list of potential projects that:

Upon a little thought, it will be obvious that these three functional requirements are very high level. To be useful in designing the system, each of these needs to be thought through in much more detail. To implement each requirement will take new processes, new tools, maybe additional staff, and a change to the technology infrastructure to accommodate the new system.

The requirements decomposition process starts as soon as management approves the high-level requirements for the EPMS. From there, design decisions will need to be made on how to status each project. How does management want to see the portfolio status reported?

These are the types of questions that need to be presented to management for decisions before any tools are configured and the system is implemented. These decisions can be made during the kickoff meeting where you have the primary players involved.

Part of the design process is understanding the technology infrastructure that will support any tools purchased or developed. If your IT network is Cisco, don’t buy any tools that only run on Microsoft networks. While your IT personnel should not be involved in defining the top-level needs, you need to start getting them involved as soon as the discussion turns to what tools do you need to buy, or on the detailed design of the system.

For each organization, the answers will be different. EPM systems will have the same top-level requirements, but below that top level, the answers and the designs will be different to adapt to the organization.

3.2.2 Requirements and Stakeholders

Many of the detailed requirements will never be seen by the users, but they are important to the design and maintenance areas. In fact, we can divide requirements into three categories:

In the first category, requirements the users care about, we have typically the following requirements you will have to obtain from the users:

In the second category, we have requirements that the users will care about but don’t think of until you ask them:

In the last category, we have requirements the users don’t care about but the technical people do. Without these more detailed technical requirements, the developers cannot properly design the system:

The requirements process takes a lot of time to do properly, but you cannot design the EPMS, understand the scope of work, or develop detailed plans until it is completed.

You will have to repeat and to customize the scope development process for each type of project that is expected to be in the portfolio, especially with regard to the filtering criteria. As we saw in the last chapter, these criteria are different for each type of project, so part of the design will be to decide the different types and then create filtering criteria for each. If your organization wants to assess 10 different types of projects as part of the portfolio, you will need to repeat the filtering criteria 10 different times and the status criteria 10 different times. A manufacturing plant that is 10 percent over budget is a much different problem than a small IT upgrade that is 10 percent over budget. Your management will need to determine these criteria.

A typical top-level set of requirements is shown in Appendix 3.2-1.

3.2.3 Capturing Requirements

Where do we get the requirements to design our EPMS? We have already captured what upper management’s expectations are, now how do we get the detailed requirements we need?

In the play My Fair Lady by Loerner and Lowe, Eliza Doolittle’s father is meeting with Dr. Henry Higgins to try and extort money from him but can’t seem to get a word in. When Higgins questions him on what he wants, he replies “I’m willing to tell you, I’m wanting to tell you, I’m waiting to tell you!”

Unfortunately the stakeholders you will need to meet are almost universally the opposite. Normal people do not think in terms of requirements, and your stakeholders are all very busy people who rarely have the time needed to meet with you to discuss what they need from the new EPMS.

There are multiple ways to capture requirements, and you will probably use several of them depending on exactly what types of requirements you are trying to identify and what would work best in your own organization:

3.2.3.1 Capturing Existing Business Processes

One primary method to capture what our EPMS needs to do is to look at the existing business process—how are projects selected now? First of all, let’s define what a business process is. A business process³ is a group of logically related tasks that use the resources of the organization to provide defined results in support of the organization’s objectives. Everything the organization does and everything it produces is a result of business processes. Selecting projects is a business process comprised of multiple steps.

Believe it or not, your organization already has a way to select projects. It is probably not documented. It probably was not even designed to be particularly efficient. It just grew and evolved over the years in response to what made sense to management at the time.

Each part of the organization developed its own way to select projects based on what made sense for them. This leads to projects that are selected in isolation from all the other projects the organization is doing. They are optimized for the group but suboptimized for the overall organization. Resources are spent on projects that do not support overall strategic goals.

The traditional way of understanding existing business processes is to simply observe each step in the process and document what that step adds to the process and who is doing it. By doing this, you will develop a flowchart of what the steps are in the process similar to the flowchart we presented in Step 2.2.

3.2.3.2 Interviewing Stakeholders

Because you’re designing and implementing a brand-new system, the most effective way to gather the high-level requirements is to interview the major stakeholders. Upper management sees the problems that the organization has in completing projects but doesn’t always see what the causes are or how to fix them. If you have gotten this far, you have already interviewed upper management and middle management to gather their expectations of what the EPMS should provide them. So, now we need to meet with them again to get more detailed requirements.

When you interview top management, be prepared with a list of the existing problems (which you can get from interviewing middle management) and how an EPMS can help manage and mitigate the problems. Rather than interview upper managers individually, it’s more effective to do this in a group setting. That allows them to see what other managers need, and they can discuss their needs more thoroughly. (An additional benefit in doing it in a group setting is that while these upper layers of managers are very time-constrained and you will not typically be able to get much of their time.) This approach also has the benefits of identifying requirements conflicts early.

There are multiple ways to gather requirements from our stakeholders:

Once you have gone through this process with upper management, you will need to repeat the process with lower-level, functional managers and with the project managers, starting with the requirements that upper management has approved. Each of them will have their own set of needs that the system should accommodate as long as they do not contradict the top-level requirements given by upper management. Ask this group how they would implement these top-level requirements. This set of requirements should then also be analyzed and prioritized. At this level, you will generally find conflicts between the needs of upper management, the functional managers, and the project managers. These conflicts will need to be resolved before more detailed design work can begin. If the different types of managers cannot reach agreement on how to resolve a conflict, the problem should be escalated to higher-level management for a decision.

For the early interviews with senior executives, the recommendation is to do unstructured interviews and help them think through what they need from the EPMS. Once you have captured these and gotten their approval for them, develop a set of structured interview questions for lower levels of managers built around the requirements you obtained from the upper levels. Make everyone you talk to aware that what they tell you will shape the system. Your design will be based on what they want.

When you do more structured interviews, do not be too rigid. Allow some flexibility in the questions asked and ask “Is there any requirement you have that I didn’t ask about?” Lower-level managers will live with the EPMS outputs on an operational basis, and they may have good ideas for make it more useful and effective. Any major changes resulting from these discussions may have to be elevated for approval, but don’t dismiss them.

Documenting the rationale for each requirement (why it is required) is a good technique to reduce the number of lower-priority requirements. According to requirements consultant Ivy Hooks, doing this can eliminate “up to half” of the requested requirements⁴.

The list of questions will change as you learn more, so put the questionnaire under configuration management so that you know exactly what the list of questions was that you asked each person.

Examples of questions that would be asked in the initial survey:

Does this all sound like it will take time? Yes, absolutely it will take time, typically it will take several weeks. But, as stated, earlier, it is absolutely critical to do and to do thoroughly. The time and resources to gather and analyze requirements should be built into the overall project plan, and nothing else should start until this effort is completed.

If you’re going to develop your own in-house software tool for portfolio management, your technical staff will develop the more detailed technical requirements that they need. If you’re going to purchase a portfolio management tool, you will need to do a search of the available tools and see which one best fits most of your requirements. Note: A caution on selecting a vendor tool—many of them only allow one set of filtering criteria. This makes them relatively useless if our EPMS must prioritize multiple types of projects. This isn’t a problem if we develop our own tool. We just build this capability into the tool itself.

Another approach to interviewing stakeholders is not to meet with them individually (there will be too many) but to meet with them in a group setting. This is more useful for lower-level executives and managers where they can see what their peers are saying. If you use this approach, have a prepared set of questions for them.

Another way to gather requirements are to have the users develop working groups. This puts them in the position where they are in charge of defining the requirements. This is best done with a restricted set of more detailed requirements such as user interfaces and security requirements.

You can improve the response rate by making it very easy to do, no more than 10 minutes long, identify who the project sponsor is, ensure it is totally confidential and that answers cannot be traced back to the responder, and clearly identify the benefits of the EPMS to the level of responder. They should appreciate that their input will help design the end result.

3.2.4 A Starting Point

A starting point for the types of functional requirements an EPMS should satisfy might include those shown in Appendix 3.2. Feel free to include other needs that your primary stakeholders can think of. As you compile these, you will see that the stakeholders may not agree with each other. When you notice this, you need to identify the disagreement and involve the stakeholders in resolving it.

Once we have the requirements collected, analyzed, and approved (getting our requirements approved is critical to avoiding future problems), we can used them to start the architecture and design efforts as well as developing the Work Breakdown Structure (WBS) from them.

3.2.5 CareFirst Case

CareFirst Inc.⁵ is a not-for-profit health care provider on the east coast of the United States. It has 5,200 employees and provides health care services to nearly 3.4 million members. The following requirements gathering process was crucial to their successful implementation of their PMO.

Figure 3.2-1a and b CareFirst requirements process

While this particular approach may not be exactly what your requirements development approach will be, it provides a very useful guideline for how detailed the requirements gathering and management process should be. Keep in mind that everything else from now on is dependent on how well the requirements capture what your primary stakeholders expect. Well mention CareFirst again later.

3.3 Architecture and Design

In this section, we are going to cover five areas:

But first, a caution. Many attempts have been made to develop a rational project selection process based on complex filters and calculations such as the Analytic Hierarchic Process (AHP) approach mentioned earlier. Most of these attempts have failed due to their complexity, and the organization goes back to doing things the way they’ve always been done. The filters themselves are not the problem, the problem is the user interface, and the lack of flexibility in rigid and overly complex filters.

The system you are developing will be used by people who have no knowledge of much of the data needed to efficiently select projects. If I am an accountant in the financial department, how can I possibly know how many people will be required to do the project and how much time it will take (two common questions asked for many commercial products)? A too-complex project request form will cause people to not use it. This is similar to hearing a noise coming from your car engine, and the mechanic asking what the root cause is, how to fix it, what tools he needs, how much it will cost, the benefits of fixing it, and how long it will take.

Keep it simple and easy for people to use and efficient enough that the project selection committee gets what it needs in a timely fashion.

3.3.1 Architecture

The tools are probably the easiest part of the EPMS. There are a lot of good commercially available tools on the market as well as Internet-based services to do portfolio management for you. Which is the “best” tool or approach depends on your requirements. As the tools companies upgrade their tools to compete with each other, the “best” tool changes from year to year.

People’s roles and responsibilities in the EPMS are also fairly straightforward. As discussed in other parts of this book, the roles of the stakeholders are easily defined. As usual, with systems such as this one, the specific roles and responsibilities will vary by organization and political influence of the major stakeholders.

Processes are not as easy to define well. In process design, you are trying to think through all the possible things that can happen in the future that the EPMS must be able to handle. For example, how does our system respond when the strategic goals change. How do you design a system that can easily incorporate changes such as this? Being able to handle changes to the basic filters will be important. (The easiest technical answer is that you store the filters in a database and not hard-code them into software.) But, how do you know which changes to make?

Another decision that must be discussed and finalized during design is what happens when projects run late or over budget. Is this the responsibility of the EPMS or of the PMO? If the project is an internal project (such as an infrastructure improvement or a process improvement), the benefits will likely be achieved even if the final result is a little late or costs a little more. Is this acceptable to the steering committee? Will they agree to let the project finish to obtain the benefits?

These types of over-runs are handled differently for projects that are done to increase profits, such as new product development projects or developing a new manufacturing facility. In this case, any delay or cost over-run will probably impact the business justification for the project. Reduced profits or increased costs may cause the project to drop off the selected list because the return on investment is no longer there. In New Product Development, there is a great deal of history to show that the sooner a new product comes to market the greater the market share it will garner, so schedule is highly important, cost much less so.

If the EPMS is to provide the full set of benefits it is capable of, it must include all the project-related work in the enterprise that requires money and people. If it does not include all the project work, then its benefits are lessened, and the projects in the portfolio are more likely to be disrupted by work that was not included. While some authors advocate scoping the EPMS to one department, typically IT, this significantly reduces the benefit of portfolio management because it does not include all the work that supports strategic goals. As we will see later, implementing an EPMS is best done in phases, starting with one department, working out the problems and improving the processes, and then rolling it out to other departments. The IT group, because its organization and mission is typically well defined, is a good place to start.

Other authors suggest limiting the scope of EPMS to the most common type or size of project the organization does. If the normal size project is between 500 and 5,000 man-hours of labor, the EPMS processes should include only those size projects. This suggestion has even more limitations than the previous one. There will be a higher degree of disruption to the portfolio that is caused by both outside projects as well as larger-than-normal projects and smaller-than-normal projects. Under no circumstances should you implement an EPMS that has this limitation. If management wants to impose this restriction, then there are better ways to manage the set of projects than an EPMS.

All that being said, it makes a lot of practical sense to put a lower limit on the size of work that goes through the selection process, so let’s not apply the process to small projects. There are just too many of them, and you often cannot plan for them ahead of time. (Really small projects are rarely high priority anyway.) Instead, limit the work in the portfolio to medium- and large-scale projects. Those are the ones that will take the most time, money, and resources. The threshold for a small project will vary by organization. When the U.S. headquarters of Toyota Financial Services installed a PMO, anything under 100 hours of work was not a project, it was just absorbed into daily operational work. Other organizations may choose a lower limit of 250 hours or greater for projects.

Part of the design process is how to handle projects already in work. This can be done in one of two ways. The first is to simply ignore them in terms of priorities. Use their project plans (we assume they have reasonably accurate plans!) to determine resource availability and after that simply monitor their progress to see if the resources will be freed as expected.

The second approach is to perform a separate assessment of them as you would a brand new project. While this has the benefit of seeing how they fit into the overall portfolio, it will tie up resources that could be used to complete the project. If the existing project would normally be approved as part of the EPM selection process, allow it to continue as planned. If it would not have been selected, then someone higher up in management must make the decision to either continue the project or to kill it and free up the resources for higher priority work.

Another item that must be designed into the overall architecture of the EPMS is how to handle regulatory projects. As described earlier, these are projects that are dictated by laws or regulations and must be accomplished. There is no need to create a business case for them because you have no choice except to do them.

One important aspect of regulatory projects is that they often have a well-defined completion date by which they must be completed. If the dictated completion date is within a short period, say six months, then the EPMS must be able to reallocate resources from existing projects and complete the work. The projects that were put on hold to free resources would then be restarted and completed. Of course, every project in the portfolio must be rescheduled due to the disruption created by the regulatory project.

While the executives on the steering committee will tell you what they want to see out of the portfolio management system, a properly designed system has capabilities that they may not be aware of but would be interested in. For example, projects are selected based on their alignment with strategic objectives. But, is it possible to go the other way? To see, for each objective, what projects support it? The answer is yes, if the system is designed that way. For each objective, I can tell you which projects advance that objective. This allows the executives to see which objectives are strongly supported by projects and which are not. It also allows them to select the projects that support objectives that are not currently being supported and to balance out the portfolio against the strategy.

Data Inputs and Storage

For most organizations, the input data will come from requestors typing in the data using the input forms described earlier. The data will be stored in the relational database registry created by the database analysts on the IT project team or within the commercial tool purchased.

If the data already exists in the organization’s current approach to selecting projects, it most likely exists in either spreadsheets or small databases. In this case, a conversion program should be developed to extract the data from its existing format, convert it to its new format, and perform whatever data cleaning is necessary.

According to Rajegopal,⁶ the list of projects should be kept in a registry that includes all of the characteristics of each project, including the type of project, duration, product being developed, service being supported, ROI, customer, and so on.

If you have poor-quality data, and to be honest most companies do, don’t overdesign the precision the calculations are carried out to. When your basic data is only 10 percent accurate, don’t design a system that calculates to three decimal places.

3.3.2 Detailed Filter Design

For your development team to create the EPMS software, it is critical for them to understand in great detail what the filters are that we discussed in Step 2.

The output of the EPMS is to provide projects filtered in a way that the most beneficial projects are scored high and less beneficial projects are scored lower. We determine what the score is by asking the right questions, weighting the questions for importance, and rank-ordering the projects based on their scores. During this section, we will develop weighting criteria such that the maximum score a proposed project can get is 1,000. The questions proposed here are generic questions that you can use to think up questions specific to your own situation.

One way to understand quickly how the executive decision makers think is to identify the projects currently in work and ask why those projects were chosen. What made them important enough to schedule? Their answers should help guide you in selecting the filtering criteria.

The questions should be grouped into logical categories such as:

Depending on what is important to the organization, we could also ask filtering questions on impacts to the environment or impacts to the neighborhood.

It is important to note that research has shown that selecting projects based on purely financial modeling and criteria fails to select the best projects for the organization. Cooper⁷ shows that while financial approaches are the most common, better results are obtained by selecting projects based on their alignment to organizational strategy rather than purely financial criteria. It is important to note that research has shown that selecting projects based on purely financial modeling and criteria fails to select the best projects for the organization. Cooper shows that while financial approaches are the most common, better results are obtained by selecting projects based on their alignment to organizational strategy rather than purely financial criteria. So, when you create weights to the different criteria, give strategic fit a higher weight than ROI or NPV. This will help improve the selection of the R&D-type projects that are more essential to the organization’s future than the short-term product development projects.

In order to gain a basic understanding of what the proposed project is, we need some high-level information about it first so that we can more intelligently answer the detailed filtering questions later. These are written descriptions and not score-able questions.

In order to avoid spending time asking for detailed information on a mandatory project we know we have to do regardless of the financial considerations, we will ask those questions first:

A mandatory project that is far out in the future, say one calendar year, 365 days away, can often be scheduled into the workload without a major disruption to on-going work, so lets assign that a score of 250 (on our 1,000-point scale). For a project that’s due between 180 days and 365 days away, we’ll assign a score of 500, and for one that’s due in less than 180 days, we’ll assign a high score of 750. Those short-term projects are very disruptive and need to be immediately approved.

For the maintenance projects, most of those can be preplanned, as we saw in the last chapter, so we will give them scores lower than mandatory projects but high enough that they will get a final high score. A maintenance project that is more than one year away will be assigned a score of 100, between six months and one year, it will get a score of 250, and if it’s due in less than six months, it will get a score of 500.

For the more detailed questions, design the spreadsheet or the database to capture: the question, capture possible answers from 1 to 5, and to allow space for comments. Each answer should be given a range of numbers appropriate to that answer. For example, a general question might be:

What is the estimated payback period for this project?

Table 3.1 Payback period duration estimate example

5	4	3	2	1
< 1 year	1 – 3 years		> 4 years	N/A

Higher scores for each question translate to higher end scores for the project. In this question, a short payback period scores a 5, while a payback period more than four years scores, a 2. Note that we are using payback period here. You can just as easily use ROI, IRR, or one or more of the other financial filters we discussed in the last chapter.

Now let’s develop a set of detailed questions that will allow us to score the proposed project. We start by determining how much we expect the project to cost. As we showed in the last chapter, this estimate is going to be a very rough guess, ±75 percent or so. We cannot estimate the costs much closer than this because we haven’t done any real analysis of the project.

3.3.3 Processes

Having the filters defined and the scoring process laid out, now how do we actually use the new system? These are business processes that must be carefully designed to be effective and efficient. That nicely explains how the EPMS will work—a set of activities done in the correct sequence that will produce the right output.

What are the major steps that a newly proposed project must go through from initial request to final approval or rejection?

Figure 3.3-1 Process steps

Let’s look first at how people will input requests into the new system. Can they do it from their desks while logged into the internal network? Can they do it through the Internet from anywhere in the world? Can any employee do it, or is it limited to a subset of the employees? This is a crucial decision that must be made by the steering committee or by the project sponsor (who is a de facto member of the steering committee).

This illustrates a typical flow for the process. Note that we have made the decision in Step 4 whether the project is mandatory or not. If it is, we skip many of the remaining steps and just score the project. However, it does not have to be in this order. Your organization may wish to gather the financial cost data for the project even if it is mandatory. In this case, we would reorganize the steps to show this.

This is the basic flow of the processes. As in any business process, there are exceptions to the normal flow. One of the EPMS’s internal processes is to ensure that projects in work are examined on a regular basis to ensure they still satisfy the original selection criteria. If a project is so late or over budget that it shows up as red on the status reports more than two reporting periods in a row, then it very definitely needs to have the business case rewritten to see if it is still justifiable.

So, what should the steering committee do for projects that are late? If the business case still makes sense, then after the causes of the overruns are determined, they need to find money to continue the project in either its present form or modified. In general, never make a process so rigid and inflexible that you cannot do manual workarounds for exceptions. No one can predict all possible future events, so build in some points where the existing process can.

If a new product project is behind schedule, the primary imperative is to find out why. If there are technology problems that are causing schedule slippage, then one option is to add more people to the project and/or to decrease scope. Adding more people onto the project is rarely beneficial, even though this is the default approach used by many managers. New people coming onto a project almost always decreases productivity of the team because experienced and productive team members must slow down and bring the new people up to speed. Fred Brooks, in his seminal book The Mythical Man-Month,⁸ showed us many years ago that cost is a factor of people multiplied by time, but progress is not. What can be done with some benefit is to carve out a piece of the late project and outsource it so that the existing team is not disrupted. If this is done as a subproject and given to someone else, the impacts to the current team are lessened.

Another approach is to reduce the scope of the new product. While painful to the marketing executives, meeting schedule is more important than adding more bells and whistles. If adding more features to the product are causing it to fall behind schedule, then the right answer is to not add as many new features. When problems like this occur in any project, the EPMS processes should include an automatic review of the business case to ensure that the project still makes sense.

Another process step that must be included is to reanalyze the entire portfolio when projects are killed. When a project is significantly late or over budget and the decision is made to kill it, the team managing the portfolio should reassess the remaining projects in the portfolio and reprioritize them as needed as well as reassessing the overall risk level of the portfolio.

3.3.4 Reports

Many software programmers enjoy the challenges of developing new software that will help the organization. Developing the output reports? Not so much. Too often, the output reports are a quick addition at the end of the design. But, that’s a mistake. The accuracy, believability, and readability of the reports given to management is going to make the EPMS successful or be ignored. If the reports are too detailed, the decision makers won’t be able to interpret them. If they’re too high level, they’re useless. Part of the requirements gather effort is to identify exactly what the final reports generated should look like and what information they need to contain. This was discussed at the end of Step 2.2.

3.4 Scheduling the Project

Law of Project Management

In any large organization, no major project was ever installed on time, within budget, with the same staff that started it. Yours will not be the first.

Implementing an EPMS cannot be done quickly. For the EPMS to be successful, the people who are affected by it must be totally committed to working within its framework. They must buy into the idea and the processes. This will require time and multiple meetings with management (be honest—how easy it is to get even four managers together at the same time for a few hours?). Organizational change does not come quickly. In a small organization, you should expect at least a year to get approvals, design the EPMS, implement it, and get buy-in by everyone. IDC⁹ published a survey of 13 companies that had deployed an EPMS for at least a year. The average time from the project charter to operations was 37 months. For a large, multinational organization, plan on 2 to 3 years for a successful enterprisewide implementation. For government agencies, where there are multiple groups with different reporting geographies and significantly different priorities, it can take even longer before the EPMS is truly effective. The project phases in a top-level schedule might look something like this:

Note the duration of the project is over two years long the way we are laying it out (assuming 250 working days/year). As in every project, there are a lot of uncertainties and assumptions in duration estimates. Yours may be much longer or much shorter than this, depending on your individual circumstances. How do we get to an accurate estimate? That’s what this section is about.

Figure 3.4-1 Top-level schedule

3.4.1 WBS

As with all projects, we start the process of developing the schedule by defining the high-level deliverables that need to be done to do the work. This list is called the Work Breakdown Structure, the WBS. The requirements tell us what has to be developed, the WBS tells us what the major pieces of the final product are. Then, we define the specific activities to design and produce those pieces. These are the activities that must be completed to successfully deliver the project. The WBS is not a very detailed list, just detailed enough to define the major activities. This is not something you do in your cubicle by yourself. Developing the WBS is a team effort of the major team members. This not only gives you a more accurate WBS it also gives them buy-in to the resulting list of activities. That buy-in makes them more committed to the project work. After all, they’re the ones who gave you the activities.

The top-level WBS might look like this:

Table 3.2 Top-level work breakdown structure

1.0	Project management activities
	1.1	Project initiation
		1.1.1	Identify primary stakeholders
		1.1.2	Develop project charter
		1.1.3	Obtain charter approval
	1.2	Develop management plans
		1.2.1	Schedule management plan
		1.2.2	Cost management plan
		1.2.3	Stakeholder management plan
		1.2.4	Communications plan
		1.2.5	Requirements management plan
		1.2.6	Implementation plan
		1.2.7	Quality plan
		1.2.8	Risk plan
		1.2.9	HR management plan
		1.2.10	OCM plan
		1.2.11	Test and integration plan
		1.2.12	Configuration management plan
		1.2.13	Procurement plan
		1.2.14	Management plan approval and baseline
			Go for project execution
	1.3	Project execution
		1.3.1	Identify EPMS requirements
		1.3.2	OCM project plan
		1.3.3	Detailed design and development
	1.4	Testing and integration
		1.4.1	Define test requirements
		1.4.2	Create test data and develop test cases
		1.4.3	Integration testing
		1.4.4	System testing
		1.4.5	Stress testing
	1.5	Implementation
		1.5.1	Management approves pilot project
		1.5.2	Pilot EPMS
		1.5.3	Get management feedback
		1.5.4	Make changes as needed
		1.5.5	Approval to roll out
		1.5.6	Incorporate new proposed projects
		1.5.7	Incorporate existing projects (if approved)
		1.5.8	Begin new project selection process

Notice that this is built around the top-level deliverables on the project. Once you are comfortable that you have captured the major pieces of the EPMS product, the WBS should be communicated to your project sponsor and the steering committee for review, discussion, and approval. Your job is made much easier if they understand what the members of the team will be doing. The WBS is signed by the project sponsor or, even better, by the steering committee. This creates a baseline that cannot be changed without going through the change approval process.

Once the WBS is approved, we can take it down to lower levels of detail in a process called decomposition. To each activity in the WBS, we determine the relationships among the various activities, add resources to them, and determine their duration, and finally, customize the project and resource calendars to determine the overall project schedule. How detailed should the schedule be? Detailed enough to plan what has to go on, but no more detailed than that or else it becomes too burdensome to manage.

Let’s take this highest level now and break it down into the next level of detail:

And, as shown in the example in the Appendix, we can decompose the activities until they are detailed enough to allocate resources to and to develop the activity relations and durations.

The WBS in the Appendix that is sufficiently detailed for you to use it as a template and customize it for your own use. Caution: Never blindly follow a template. A template provides thought guidance for you to help think through what you are doing. It’s not a cookie cutter to be used without changes.*

3.4.2 Estimating

Once we have a good WBS at a reasonable level of detail, we can start the process of developing the schedule. The recommended sequence is to work with your team to determine the sequence of activities. What has to come first, second, third, and so on. What needs to be done sequentially and what can be done in parallel.

A major input to this process is the size of the team and the skills of the project team members you have. The more team members working on the project, the faster the work can be completed, but at a high cost. This is not absolutely true, but it works up to a point. Fewer team members will lower the cost, but the work will take longer. For every project, there is an optimal range of team size that will complete the project efficiently. We’ll talk more about resources later.

Once you have the “right” number of people assigned to each activity, the team can estimate the duration for each activity.

This is a major danger point at which projects are either successful or run far beyond their due date. Accurate estimating is one of the most critical parts of scheduling and costing as well as being one of the things we do most poorly. Being trained in estimating provides a significant improvement in the estimates, but no estimate is perfect.

Each activity has uncertainty in its estimates, both cost uncertainties and duration uncertainties. If I can estimate an activity’s duration within ±10 percent, I feel confident I can complete the activity as planned. If my critical path has 50 activities on it, and each one has a 10 percent uncertainty in the duration, that can either cause the project to complete extremely early if each activity finishes 10 percent early (causing you to be accused of padding the schedule) or finish extremely late if each activity finishes 10 percent late (causing you to be accused of incompetent scheduling). What will most likely happen is that some activities will finish earlier than planned, and some will finish later than planned. So, on average, you should finish close to the planned schedule if you’ve done a reasonable job developing the schedule.

Projects are, by definition, unique. This project you’re planning has never been done before exactly this way, so you have no history to rely on for the needed activities or their durations. You’re trying to predict how long something is going to take when the work itself is weeks or months away. You’re trying to predict the future, and nobody is good at that.

We can improve our estimates by using three-point and PERT (the well-known Project Evaluation and Review Technique) estimating techniques, and even better, by using Monte Carlo simulation on the project schedule. But, that kind of detailed schedule analysis is probably not required for an EPMS project.

Even though we don’t need to use sophisticated statistical analytical methods for our schedule, there are simple things we can do to improve the accuracy of our scheduling process. One simple thing is to build individual calendars for each team member and put in the days they’re not available for project work due to vacation, planned holidays, and other known off days.

Another simple scheduling trick is to not use the default 40 hours per work week that is built into the scheduling software. Why not? Think about what you’re scheduling at this phase of the project. You’re planning out the work that people will do on the activities weeks or months from now. But, once we’re in the middle of the project, we demand that our team members do a lot of things that are not planned activities. Weekly status meetings, change-control board meetings, writing status updates, risk meetings, and many other activities take up time that wasn’t planned for at the beginning of the project. On a normal project, these can take up a full eight hours a week.

Think this is way too much? CIO¹⁰ magazine published a survey that Intel Corporation did of their own internal knowledge workers. Their research showed that their workers spent about 20 hours/week just on e-mail, and that about one-third of that time, or six hours per week, was wasted. As a result, Intel instituted a “no e-mail Friday” policy.

If you use a standard 40 hours/week, you will force people to put in overtime in order to take into account all these other normal activities. To compensate for this, change the default work week to about 32 hours per week. This is most easily done by changing the default day to 6.5 hours instead of 8. The schedule you put together will be longer than if you used eight hours/day, but it will be more accurate and you will spend less time explaining why your project is late. We want to be as realistic as possible when developing a schedule.

3.4.3 Turning the WBS Into a Schedule

So, now let’s start turning these WBS items into a schedule. For the remainder of this section, we’ll assume that we have all the resources we need, and that there are no resource limitations or conflicts. In real life, you’ll have to deal with these, but for now, let’s ignore these constraints.

3.4.3.1 Scheduling the Project Management Itself

The top-level schedule was shown earlier. Now let’s break down the initial project management activities and development of the management plans.

The primary activities here are to write the project charter and get it approved, write the various management plans, and hold the kickoff meeting to begin the communications effort. Identifying the stakeholders and the goals of the project are intrinsic to developing the project charter.

The initial project activities generally end with the project kickoff meeting. After that point, the project can be considered to enter the execution phase where the planning is substantially completed, and the project team members can begin work.

Figure 3.4-2 Project management planning schedule

Note that the management plans are developed in parallel for the most part. The assumption here is that you have reasonable templates to work from, and that all you have to do is fill out the project-specific pieces of the template. If you don’t have templates to work from, you should add several more days to each of these. If you don’t have enough resources to help, you may need to do these in sequence rather than overlapped. That would require 41 days instead of the 33 shown here.

Note also that we have included what are referred to as “living documents” such as the risk register. These documents generally do not take much time to develop, but are constantly updated as we go through the project. Schedules and budgets are updated weekly, the others are updated as required during the project. Other documents that you will need include a stakeholder register, requirements tracking documents, and others as required.

How much of each person’s time should you plan on them for? How much of each step should you allocate to different people? For, planning purposes, as a guideline, look at the chart shown after the RAM to help you think through each step in the process and how much time to allocate (this could be taken into account during the scheduling/costing effort to provide more accurate budget numbers). Note that the numbers do not have to add to 100 percent. During the requirements analysis, 100 percent of the business analysts’ time should be devoted to the activity, but only 25 percent of the project manager’s time (he/she will be more involved in development schedules, budgets, etc.). Allocations should be made as shown in the Appendix 3.4-3 example.

3.4.3.2 OCM Planning

Once we begin the execution phase of the project, the primary activities are developing the detailed requirements that we need to design the EPMS, start the OCM processes, and do the detailed design and development. Let’s take a closer look at the OCM effort. OCM is not a project, it is a program that will not only prepare the organization for the upcoming changes, but may continue after the EPMS has been implemented. At the top level, the activities are:

Figure 3.4-3 OCM planning schedule

More details of the rest of the OCM processes are in Appendix 3.4-1.

By developing this level of detail, we can see how the OCM effort evolves and ensures that everything that should be thought of has in fact been identified. For our example, we have come up with an OCM effort duration of 133 days. In reality, OCM is like project communications—it goes on as long as necessary to ensure the stakeholders are satisfied. Don’t take the 133 days as a fixed duration. Efforts like OCM are highly dependent on the results they produce. If they need more time, give them more time. The results of the effort are critical, not how long they take. The OCM effort is not on the critical path once the execution phase begins and should continue as needed to get buy-in for the project.

3.4.3.3 Requirements Planning

Unlike OCM, the effort to identify and develop the detailed requirements for the EPMS can be scheduled much more precisely as shown in Appendix 3.4-2. We can see that we can schedule the specific activities needed, whereas in OCM, the activities are more reactive to how people respond to the project. Note that the project’s critical path goes through the requirements. This should always be the case for a project.

Five months to develop requirement (and that assumes you have the staff to gather requirements in parallel)? That seems like a really long time, doesn’t it? BUT, it is absolutely critical to get the requirements 100 percent correct. The success of the project depends on the completeness and thoroughness of the requirements. Remember that, for any project, the requirements have to be approved and signed off by the senior decision makers. This takes more time and more coordination meetings than you would think. Be prepared to answer a lot of questions about where the requirements came from, why each one is important, why do they have the priorities they do, and many other detailed questions. By the end of the process, you will likely have memorized the entire set of business requirements.

When identifying the sources of requirements, we have to include sources such as business analysts, executives, existing process documentation, project managers, functional managers, and other stakeholders as discussed earlier.

3.4.3.4 Design and Development

Now that we’ve defined our requirements and begun the OCM process, let’s look at the details of design and development activities in Appendix 3.4-4. If there is a commercial product to be purchased, the schedule there is a little less predictable because of the delays inherent in purchasing anything from an outside vendor. We have the actual purchase shown as only one day, but in reality, it can take weeks to get through the procurement process.

Figure 3.4-4 Detailed requirements development schedule

Figure 3.4-5 Design and development schedule

These are reasonable steps for the project in a reasonable order. As so many technical consultants like to say: Your mileage may vary. You should feel free to use these schedules as guidelines but to develop your own that will work in your organization.

Somewhere between the design and the implementation steps, you will have to train employees and managers on how to use the EPMS. If your organization has a training department, they can help identify the training requirements, develop training materials, and schedule training sessions for everyone who might interact with the system. The training for employees to enter a new project request should be short because, of course, you’ve made the input forms simple. The training for managers to understand and interpret what the output of the EPMS is will be longer and more detailed.

3.4.3.5 Testing and Implementation

The final processes in the schedule are testing and implementation as shown here:

Figure 3.4-6 Test and integration schedule

Isn’t the testing phase part of development? Yes and no. It’s the experience of this author and many software project managers that because most project managers don’t come from a testing background, they tend to short-change testing when it comes to the schedule. It takes more time than you think to develop a strong testing program and the process starts as soon as you’ve identified the requirements.

The testing should be against the requirements, not against the design, and it should be done by a group independent of the developers. If you test to the design, the design will almost always pass. If you test to the requirements, the design may or may not satisfy the requirements, and this is the place to catch that shortfall. This is why, there is a schedule gap between the first activity “Define test requirements” and the second “Create test data and develop test cases.” You can start the testing design early, but you cannot develop test cases or test data until the requirements are complete.

Testing will prove to be the most challenging part of the project to schedule due to the uncertainties of test results. If a module is tested and passes the test, the test results are written up, and the module is set aside for integration testing and the tester moves onto the next module. But, if the module fails the test, the test failure is documented, and the module is returned to the development team for rework. Now the developers have to figure out what went wrong and fix the module. It then goes back for retesting. The time spent in rework by the developers and the retesting is unplanned work. It’s not in the schedule. So, a test failure causes schedule pressures on the project.

We can compensate for this uncertainty a little bit by using our historical data (you do have historical data for IT testing, yes?). If history shows that 25 percent of software modules fail testing the first time, we can compensate for it by adding an appropriate amount to each test duration to take into account the rework required. Alternatively, but this is not officially recommended, add supplementary tests into the testing schedule for rework. This is not recommended because experience shows that once management sees these activities, they will demand they be taken out of the schedule. Their logic is that people will do their jobs correctly and so we should not add rework activities that assume failures. Unrealistic, but this is how management thinks.

Figure 3.4-7 Implementation schedule

The implementation itself should begin with a pilot project. Test the new EPMS by running one or two existing projects through it and see if they would pass. Discuss the results with the steering committee and get their feedback. If you need to adjust the financial filters, do it now and rerun the pilot project. Keep doing this until the decision makers are happy with the answers and trust what the system is telling them. At that point, you can roll out the EPMS to the organization and start taking requests for projects.

At Toyota Financial Services, we first implemented the EMPS manually. Any employee could send an e-mail suggesting a new project. The information would be taken and input to the system manually at first. Once we had the bugs worked out and the steering committee was comfortable, we automated the process using Lotus Notes. The time needed to identify the details of a proposed project and to get it approved went from months down to two weeks.

3.5—Budgeting the Project

3.5.1 Budgeting Uncertainties

Budgeting any project is more straightforward than developing the schedule in most areas of project management, but it is also less certain and has more variables. If you can develop the schedule to within ±10 percent, you’re doing well. But, if the schedule uncertainty is 10 percent, then the budget uncertainty is going to be closer to 20 percent.

Why? The budget has its own uncertainties, and these sit on top of the schedule uncertainties. We know intuitively that the longer an activity goes on, the more it costs. Let’s use an artificial example to illustrate how great this uncertainty can be. Let’s look at the simplest possible project—a series of activities that are completely sequential as shown here:

Figure 3.5-1 Sequential activities

For the purposes of this example, we’ll state schedule uncertainties for each activity as shown in the following Table 3.3:

Table 3.3 Duration uncertainties

Activity	Duration in days	Duration uncertainty
A	20	10%
B	80	25%
C	60	10%
D	40	10%
E	40	10%
F	60	15%
G	100	10%
H	20	10%
I	0	-

Note that we picked a very simple uncertainty, ±10 percent, 15 percent, or 25 percent. A more realistic spread would be something like -10 percent to +20 percent. There is nothing that says the schedule uncertainty needs to be symmetric, but it makes the example easier.

To get the uncertainties in each activity, we will multiply the planned duration by the uncertainty, and then either subtract the uncertainty from the planned duration to get the optimistic duration and the pessimistic duration.

Activities A through E will cost us $1,000 per day. Activities F through H will cost us $1,500 per day. Given these figures, what is the range of dates the project can take and what impact does that have on the project costs? See Table 3.4:

Table 3.4 Cost and schedule uncertainties

Activity	Duration	Duration uncertainty	Optimistic duration	Pessimistic duration	Least cost	Highest cost
A	20	10%	18	22	$18,000	$22,000
B	80	25%	60	100	60,000	100,000
C	60	10%	54	66	54,000	66,000
D	40	10%	36	44	36,000	44,000
E	40	10%	36	44	36,000	44,000
F	60	15%	51	69	76,500	103,500
G	100	10%	90	110	135,000	165,000
H	20	10%	18	22	27,000	33,000
I	0	-
Project					442,500	577,500

The nominal project cost is $510,000 based on the original predicted durations. But, now look at those bottom row numbers. Just based on the schedule uncertainties, the project can cost anywhere from $442,500 to $577,500. That is a difference of over $150,000. How are you going to explain that to management unless you prepare them in advance for the reality of schedule uncertainties? Remember we said that during the kickoff meeting, you have to ask management what level of uncertainty they’re willing to accept? This is why.

Now lets go one step further. As we said earlier, there are budget uncertainties that are independent of schedule uncertainties. For example, when you identify the team members and add their cost to the project activities, what cost do you use? For contractors, the costs are defined in the contract and known. But, for employees, the situation is different. In most countries, you’re not allowed to know their actually salaries. That’s a violation of their privacy. So, you go to the HR department and get the average salary for the job grade of each required skill set you’ve identified.

If the team member assigned to the project has been there for years and has a salary higher than average, the activities she works on are going to be more expensive than planned, and your budget is going to look bad because that team member cost more than you expected. You could not have predicted this.

If the team member assigned is new to the company and relatively inexperienced, their salary is going to be below average, and your budget is going to look good. You could not have predicted this either. Other sources of cost uncertainty include the future cost of purchased materials and contractual changes.

So, there are impacts to your budget that were unpredictable. Let’s take these into account and extend our example to take into account these uncertainties. As before, we will use reasonable budget uncertainties for each activity, say ±10 percent. But, this time, the budget uncertainties will be added on top of the schedule uncertainties.

Why use 10 percent for uncertainty? Because it is a relatively common level of uncertainty in many projects. Using the same cost numbers as before, we can multiply the optimistic and pessimistic durations by the cost uncertainties and subtract or add the uncertainties to get the optimistic and pessimistic cost numbers. In Table 3.5, these are labeled “Budget Most Optimistic” and “Budget Most Pessimistic.”

Table 3.5 Total project cost variation

Activity	Duration	Duration uncertainty	Cost uncertainty	Budget most optimistic	Budget most pessimistic
A	20	10%	10%	$16,200	$24,200
B	80	25%	10%	54,000	110,000
C	60	10%	10%	48,600	72,600
D	40	10%	10%	32,400	48,400
E	40	10%	10%	32,400	48,400
F	60	15%	20%	61,200	124,200
G	100	10%	25%	101,250	206,250
H	20	10%	10%	24,300	36,300
I	0	-	-
Potential project total costs				$370,350	$670,350

Look at those bottom-line costs! Wow! That’s a range of $300,000 between the absolute best the project can do and the absolute worst. And, this analysis didn’t even do a thorough risk assessment, we just looked at the normal uncertainties in the schedule and costs.

Obviously, this example was developed to show extremes. The average project should come in somewhere relatively close to the planned. Just as in schedules, some activity costs will come in above planned and some below. So, the average of many activities will be closer to planned than to the extremes (assuming you did a reasonable job in estimating your costs).

3.5.2 Costing the Project

When you develop your budget, what costs do you put in? Certainly, the salaries of each team member (constrained by the uncertainty mentioned previously) and the contract costs of any contractors used. For a pure software project, the costs are almost exclusively salaries of team members. For other types of projects, such as construction, there are a multitude of other costs associated with the work.

Part of the project’s budget is contingency funds for risks. If a risk happens, it will have cost and schedule impacts. There are methods to develop a detailed risk budget, but for a project such as this, the amount of time required is probably not worth the benefits. A simpler approach is to take an industry average for similar projects. In this case, because there are risks both from staff resistance to the EMPS as well as software risks, take 25 percent of the final planned cost and ask for that as contingency funds in addition to the planned budget. If you have multiple risks on your project (and you do), at least some of them will happen. You just don’t know which ones. So, protect yourself by asking for contingency money at the beginning.

Some of your personnel resources will not be counted against the cost of the project. For example, you will need to interview the executives while gathering requirements and meeting with them to status the project and to get feedback. Their costs are typically not accounted for on the project but are covered in overhead. If you meet with functional managers and project managers, their time is also not typically charged against the project.

If you are planning on buying a software tool as a portfolio management tool, the cost of the tool will count against the project as will the cost of the IT department’s implementation of the tool, the configuration of the tool, and the testing to ensure the tool does not interfere with other existing software.

Before you even begin, management will ask you how much, roughly, this EPMS implementation will cost. They need to know that so that they can decide if they want to pay for it or not. At this stage, before the project is approved, the cost is going to be very inexact. A figure that is ±50 percent is often good enough.

More detailed costing can only be developed after we have a detailed schedule. We ’ll estimate the resources needed and their hourly salaries to arrive at a cost for the project. Let’s start with the OCM activities as an example. In Table 3.6, we show the salaries we have assigned the resources:

Table 3.6 Project salaries

Resource	Cost
Project manager	$0/hr
OCM lead	$75/hr
Communications lead	$50/hr
Lead business analyst	$30/hr
Business analyst 1	$25/hr
Business analyst 2	$25/hr
Trainer	$50/hr

Not that the project manager has a zero cost associated. This is because that salary has already been allocated to the general project management activity. If we put in an hourly salary here, that would give us double booking of that salary and result in an inaccurate final cost.

We allocate the resources against the most detailed activities in the schedule to come up with the total number of hours the resource worked and the costs for each resource. Remember a statement we made at the beginning of this section: The numbers are only accurate to within 10 to 20 percent. So, take the scheduling tool’s cost numbers carefully and add 20 percent management reserve.

As an example: how much does it cost to perform the activity “Create a Sense of Need Among Stakeholders?”

Note 1: For some resources that work throughout the project, such as the project manager and project administrative assistant, it is easier to enter their costs on a daily rate for the duration of the project instead of trying to attach their costs to specific activities. They are working on the project even if they are not tied to a schedule activity. If the schedule is 381 days long and the project manager makes $100/hour or $800/day, the cost for the project manager is $304,800. Similarly, if the project admin assistant makes $25/hour, their cost to the project will be $76,200. You enter these as fixed costs at the top level of the project rather than as activity-driven costs.

Note 2: If you work in a matrix organization, then you assign resources to the individual activities and determine their costs. When they are not needed on the project, you return them to their home shop and no longer count their cost against the project. If you have a dedicated team for the duration of the project (common in projectized organizations), you simply multiply their salaries times how long the project is just as in the previous note. For the purposes of this example, we’ll assume that we only pay for the work team members do on the project, except for the project manager and the admin assistant.

Figure 3.5-2 Cost for creating a sense of need

The entire OCM effort will cost:

Figure 3.5-3 OCM costs

If you’re wondering where some of the odd numbers, such as $31,039.95 under communications come from, it’s because communications is not a 40 hour/week effort. So, we allocated only 25 percent of the communications lead time to the activity. The odd numbers are constraints in the software’s calculation for the effort. Remembering that these are only estimates, instead of showing $31,039.95 for communications activities, round it up to $32,000 or so. It’s just as accurate.

Similarly, we can identify the detailed costs for gathering the requirements, making the same assumptions as before. The costs for 116 days of work to determine and lock down the business requirements are in the range of $130,000. Expensive? Sure, but much cheaper than NOT developing solid requirements and spending the rest of the project adapting to continuously changing requirements during the execution phase.

Doing the same thing for the rest of the project gives us a project cost as shown. We end up with a cost of $1,700,000+ for the project ±10 percent:

For the project manager, we gave them an hourly salary of $100 and the project admin an hourly salary of $40 and then just multiplied that hourly salary times the number of hours in the project’s duration.

This sounds like a lot of money, and management will push hard on justifying spending almost $2 million on a new system. But refer back to Section 1.3. The research done by IDC shows a return on investment of $5.57 for each dollar spent on an EPMS. So, you can tell management that this investment will return almost $9,000,000 by doing this project. That’s a lot of savings and benefits.

Note that we have deliberately ignored some costs. We’re assuming that your organization has a Quality Assurance/Quality Control group already in existence, so the cost of managing the quality of the EPMS will come under their purview and not be charged against the project budget.

3.6 Quality Expectations

This is where we start getting into the fuzzier aspects of project management. There are no calculations here, and the only filters are the mental expectations of management and of the users. If you can identify and satisfy those expectations, you will have produced a high-quality EPMS.

What does quality mean to you? When you go to buy a car, or a television set, or a new software application, how do you judge it? What tells you it’s a quality product? How would you judge the quality of an EPMS? More importantly, how will the users and the decision makers judge the quality of the EPMS you will be delivering to them? As U.S. Supreme Court justice Potter Stewart said in 1964 about obscenity, “I can’t define it, but I’ll know it when I see it” (rephrased). Quality is unfortunately treated much the same way.

ISO 8402 defines quality as “Quality is the totality of characteristics of an entity that bears on its ability to satisfy stated or implied needs.” I’m not sure I understand what that really means. It’s hard enough to satisfy stated needs, it’s virtually impossible to satisfy unstated, implied needs.

The Project Management Institute (PMI) defines quality as “The degree to which a set of inherent characteristics fulfills requirements.” That’s somewhat better.

But, probably, the most useful definition of quality comes from Juran “Quality is fitness for use.” If the product does what I expect it to do, it’s a quality product. A Proton (a Malaysian-made car with a reputation for unreliability) can be a quality product just as a BMW or an Audi can if it meets my expectations regardless of whether I have low expectations or high ones. An article published in Air Transport Magazine in 2013 showed that people who fly discount airlines are generally satisfied with their flights because they did not expect anything other than to arrive safely and close to on-time (that explains a lot about Southwest Airlines).

What does quality mean for an enterprise portfolio management system? Ultimately, that is a question that you will have to ask your users and your executives, but in general, we can state the following, very-high-level quality objectives:

The first three are tied to the functional requirements. Those are what the decision makers want out of the EPMS. The next six are tied to nonfunctional requirements.

If it satisfies management’s expectations, both stated and unstated expectations, it is a quality product. Unfortunately, management may not come out and tell you that it should be easy to use and cheap to maintain, those are often part of the unstated expectations that will make it hard for you to decide if you have satisfied them or not.

The best approach is to identify the quality expectations as requirements, if possible. For example, the prior statement “provides a historical record of projects” can be entered into the development as a requirement that must be satisfied. For other expectations, this becomes more of an interpretation than a requirement. “Easy to use” means different things to different people and is virtually impossible to quantify.

Of course, much of the technology depends on the requirements you pulled out of the users. If they’re too busy to spend time to determine and communicate what their expectations are, the system will not satisfy them, and they’ll decide that it is “poor quality.” This is where requirements and quality intersect. It’s a poor-quality system if it doesn’t satisfy my requirements.

There are three major categories of quality requirements for an EPMS.

User Interface

The first category is the user interface. It should be easy to use (intuitively obvious). The users, upper management, don’t care what happens behind the screens, they care about (a) does it do what they want and (b) is it easy to use. Everything else is just technology to them, and they trust the techies to do a good job with that. This is the area where the techies in your company, or vendors you hire, should shine.

Alan Cooper¹¹ recommends having members of the development team identify typical personae (in today’s Internet environment, we would call them avatars) of the expected users and interact with the software from the perspective of that user. This allows the developers to look at the interface from the perspective of the normal, untrained, busy user.

Behind-the-Screen Quality

The second major category is the “behind-the-screen” technology. If the system takes two hours to generate a report, or keeps crashing, or doesn’t present accurate data, it’s a poor-quality system, no matter how easy it is to use. This is the second area where the techies in your company, or vendors you hire, should shine. This part of the project depends entirely on them and your ability to manage the development. And, of course, on whether you gathered the technical requirements thoroughly.

The Output

The output is the final deliverable from the EPMS. This is the list of rank-ordered projects that is produced for management by the system. It is a “quality product” only if management agrees that this is a reasonable selection of projects and they would have picked the same projects.

Project Management Quality

Separate from the quality of the final product, a third major category is the quality of the development effort. If you keep bugging the management to get their requirements out of them, they will just find you irritating. If you fall seriously behind schedule, or far over budget, you’re not doing a quality job managing the project.

Is the project well managed? Is the project manager following the established processes in our organization? Or, if we do not have established processes, is the project manager following industry best practices? While project managers have a lot of discretion in how to best manage their projects most effectively, it is best to either follow the organizations established processes or get a deviation from them approved by management.

Project managers need to be optimistic about their projects. If you do not truly believe you can complete this effort successfully, you will never convince anyone else of it. But, that optimism can sometimes cause you to be less than objective about problems. You may downplay risks as being less serious than they are. That small schedule slip may portend something serious slowly happening.

Highly experienced project managers have learned that it can be very helpful to get someone objective to occasionally look at the project and give them guidance. This is what project auditors are trained to do. They cannot tell you if you have the right technical solution or the best design, but they can give you feedback on how well the project is being managed and where you might want to make changes.

Project managers in some industries, such as the financial industry or in government projects, are well familiar with auditors and can expect to be audited randomly or regularly if the project is seriously behind or over budget. Scared of auditors? Then, call them project reviewers and see how they can help you.

Because an EPMS is a complex socio-technical system, we can expect that we probably got most of it right if we followed the processes in this book but that we’ll need to make changes later on. As people use it, they will come up with ideas for improving it and making it more useful to them. You should plan on doing a user survey in three months or in six months to get feedback on whether it met their expectations or not, and how to improve it now that they have used it for a while. Even while you’re developing this first project, you should consider the possibilities of a follow-on project in a few months to make adjustments to the initial delivery.

3.7 Risk

Law of Project Management

A little risk management saves a lot of fan cleaning.

We talked about risk analysis in the previous chapter as it applies to identifying projects to review within the EPMS; now let’s discuss risk more specifically about the risks involved in developing and implementing the EPMS itself.

Every project has risk associated with it, and this one has more risk than your normal IT project. As we discussed in Chapter 1, when you make changes to how people work, there will be resistance. And, resistance creates risk—lack of cooperation, risk of schedule delays, risk of continuous change requests, refusal to use the system that’s delivered, and so on. Unless you have identified these risks in advance and are prepared to deal with them, the project will suffer. If you want to make the project successful, you will spend time identifying those things that can keep that from happening.

Let’s look back at the Risk Breakdown Structure we developed in Step 2.4 and make it more specific to this effort. This divided risks into four generic categories:

Shown as a mind map, the typical risks (you may well have others!) we would concentrate on are:

Figure 3.7-1 Mind map of risks

Think also about the risk question templates we discussed earlier. This approach is a reasonable one to take for our EPMS project also.

Let’s look at very common risks in developing a major infrastructure project such as an EPMS.

3.7.1 Organizational Risks

Multiple Projects

Common situation: We live in an environment where there is not just one project being done, but multiple ones. After all, isn’t that why we’re developing a portfolio management system?

Risk impact: This multiproject environment creates risks for us. We’re competing with all the other projects for resources, for management time, for priority, and for budget. A common risk in this environment is created by multiple projects using the same resources. If one project runs late and ties up resources that I need, that creates schedule problems for me.

Mitigation approach: Ensure you are aware of other ongoing projects that are using your planned resources and any schedule issues they may be having. It’s best to have a bi-weekly or monthly status review of all projects in work.

Low Priority

Common situation: The most common situation is when our project conflicts with other projects or with ongoing operational work.

Risk impact: W will be out-prioritized, and the EPMS work will slow down.

Mitigation approach: Hopefully, this will never come up. Your EPMS project should be the #1 priority from the start; otherwise, you shouldn’t be doing it. If your priority changes, there needs to be a serious discussion with the steering committee to see if their priorities are changing.

Resource Availability

Common situation: This is tied to not having enough of the right skilled resources that is mentioned in project-related risks. This is a result of not having the resources available when you need them.

Risk impact: The resources you need for the project will not be available when needed. This could be a lead developer, a critical business analyst, or even a manager who doesn’t have the time to communicate what she needs from the EPMS. A significant impact on schedule is usually the result.

Mitigation approach: The project manager should never assume that the resources will be available when needed. This is something you need to monitor constantly to ensure there won’t be any problems as you get closer to needing specific resources.

Hint: If a manager is too often not available to meet with your team, this may be an indication that they are not fully supportive of the EPMS project and will cause further problems in the future. Always be on the lookout for this behavior.

Funding Limitations

Common situation: You have been given approval for the project, but with the caveat that you reduce the budget by 10 percent because “we can’t afford to do it for this cost.”

This is often just a manager trying to show how decisive a manager he or she is. They have probably not done any analysis to lead them to this conclusion, it is just their normal reaction to any budget given them.

Risk impact: You will be forced to do the project with less-than-required funding. But, a reduction in cost will reduce the scope of work. (There is a famous Dilbert cartoon where Dilbert’s pointed-haired boss tells him to reduce the budget by 10 percent. When Dilbert objects, the boss says that anything can be cut by 10 percent without an impact. To which Dilbert responds and says “Cool. I’m cutting back to 36 hours a week.”)

Mitigation approach: As in other risks, you cannot prevent a manager from telling you to cut back by a percentage, but you can prepare an impact analysis showing what cannot be done if the budget is reduced and present it at the next status meeting to the steering committee.

Politics

Common situation: This is probably the most common risk among organizations large enough to develop an enterprisewide portfolio management system. At the upper levels of most large organizations, there is always political maneuvering taking place.

Risk impact: This can be a major risk because any change in the organization can have a significant impact on the project, to the point where it is canceled outright if a new manager is one who doesn’t support the EPMS.

Mitigation approach: There is unfortunately very little you can do to mitigate this risk. The best approach is to keep good communications with upper managers so that you hear about things changing as early as possible. This is one of those risks that project managers worry the most about—the risks they don’t see coming and have no control over.

Change Resistance

Common situation: The people who will use the system don’t want to change how they’re working right now.

Risk impact: The organization will spend a lot of money and effort and will abandon the final result without using it. Think this can’t happen to your project? In fact, it is very common with complex projects such as ERP implementations. Many organizations have spent millions of dollars on implementing ERP or CRM (client relationship management) systems and then abandoned them after employees wouldn’t use them.

Mitigation approach: We discussed this extensively in the section on OCM. You have to approach this very carefully and thoroughly. You won’t eliminate all resistance, but by communicating effectively, you can minimize the resistance and the impacts.

Subversive Stakeholders

Common situation: Stakeholders who, in their opinion, will be negatively affected by the success of an EPMS implementation will resist the implementation, either overtly or covertly.

Risk impact: Delay or cancelation of the project.

Mitigation approach: This comes down to keeping close communications with your stakeholders—all of them. And not just the direct stakeholders, also the people who may influence them. If you have good relationships with your primary stakeholders and open communications, they can tell you if they are hearing anything that might slow the project down.

Change of Stakeholders

Common situation: People get promoted or moved around the organization.

Risk impact: If you lose a strongly supportive stakeholder, he or she might get replaced with someone who is not as supportive.

Mitigation approach: Pay attention to changes in the organization. When there is a change, identify what the impact might be on your project.

3.7.2 Project-Related Risks

Poor Project Processes

Common situation: You are working in an organization that doesn’t have well-developed, standardized project management approaches. Each project manager does things their own way, and there’s no consistency in how projects are managed or project status is reported.

Risk impact: Research done by Serge Schiltz¹² among others shows clearly that organizations that have immature project management processes are significantly more likely to over-run project cost and schedule estimates than more mature organizations.

Mitigation approach: By yourself, you’re probably not going to change the corporate culture and implement strong, standardized project management processes across the organization. The best mitigation approach is to very clearly define the processes you’re going to use on the EPMS project and ensure that everyone involved is trained in the processes and understands them.

Inexperienced Project Manager

Common situation: This is a hard risk to admit to that we don’t have the skills to do this project.

Risk impact: That the EPMS project will be poorly planned and managed, leading to not just delays and cost overruns but the loss of credibility. A failure here will make it much harder to start up the project again.

Mitigation approach: If you are a normal project manager, you’re probably very good at managing the normal IT or business process project (which is why you were asked to do this). But, ask yourself if you have all the requisite political and OCM skills needed to navigate the project past the resisters and doubters.

Research by the corporate executive board¹³ shows that 41 percent of the top performing project managers have both IT and business experience versus 24 percent of the bottom performers who have both sets of experiences. Being able to understand both sides is really important to success as is the ability to communicate effectively to both the techies and the suits. You need both of these groups to understand and to fully buy-into the project.

Inadequate Planning

Common situation: Not having a well-developed project plan, either through lack of experience or being under severe time pressure to “show progress, don’t just spend time planning.”

Risk impact: Poor planning leading to late deliveries, cost over-runs, and loss of confidence in the project and in the project manager.

Mitigation approach: This is one area where you have the ability to significantly mitigate the risk. Plan out the planning process itself. Identify the steps, determine what resources you have to plan the project, and the relationships and durations of the activities. Too many projects have taken longer than planned because the planning process itself was not well defined. As military pilots like to say: “Plan to fly, then fly the plan.”

Poor Stakeholder Communications

Common situation: People keep calling you or e-mailing you for status updates. Management says they’re not sure what’s going on with the project. Subversive stakeholders are able to criticize the project when there’s no evidence to counteract the criticisms.

Risk impact: There is a significant risk of losing control of the project, losing its priority, and having the project put on hold until management is more comfortable with it.

Mitigation approach: There is a reason that PMI says that 50 percent of a project manager’s time is spent in communications—there are a lot of problems that are created when you do not communicate effectively. You are in full control (or you should be) of project communications. A clear, thorough, and distributed communications management plan is critical.

According to Dr. Lynda Bourne,¹⁴ “Depending on the type of project, between 50% and 90% of the risks in the risk register are associated with stakeholders.” And, for projects with heavy software involvement such as an EPMS, the number is closer to 90 percent.

The more effectively you communicate, the fewer the risks you will have to deal with. Build a project website on the organization’s intranet. Keep it fully updated with status, accomplishments, and risks and continually point people to it for project information.

Insufficient Skilled Resources

Common situation: Not having the right skilled resources to develop and to implement the EPMS. This is related to the availability of the resources you do have.

Risk impact: That the work will not get done in accordance with the plan. The project will be late and potentially canceled if management does not see progress.

Mitigation approach: The project plan needs to be fully integrated among schedule, scope, and cost. The only way to fully integrated all of these areas is by developing the details of the resources needed to perform the work. During the schedule development effort, identify every resource you need by skill set so you can easily recognize whether you have the requisite skills in-house or need to go outside the organization to get them.

The Association for the Advancement of Cost Engineering International (AACEI)^† strongly recommends not developing a schedule without having the resources fully identified and loaded. Research done by the company Independent Project Analysis¹⁵ shows a significant improvement in project performance when cost, schedule, and scope are fully integrated.

No Control Mechanisms

Common situation: This is the area of project governance. Who is ensuring that any project in the organization, including yours, is being well managed and in accordance with either approved PM standards or recognized best practices?

Risk impact: While lack of control mechanisms won’t cause you any specific problems, they will prevent early identification of problems that you might be running into.

Mitigation approach: If there are no established control mechanisms in place in your organization, you should have a discussion with the steering committee on performing that role. This has two advantages: it provides some objective oversight for your project and it makes them feel more involved (making management feel more involved is always beneficial to a project manager).

3.7.3 Technical Risks

Inadequate Requirements

Common situation: This is one of the major killers of projects—not thoroughly understanding the full set of detailed requirements. Either through not appreciating that your success largely depends on understanding what management wants, not having the resources who understand how to do this, or being under serious schedule pressure to get it done quickly.

Risk impact: This can be potentially a major risk for the project, depending on just how many of the requirements are missing or poorly phrased. Most of your really important requirements are business requirements, not purely technical ones. In the worst case, the project will be in such poor shape, it will be canceled.

Mitigation approach: Plan heavy commitment from your business analysts early in the project. Defining the business requirements is a core part of their work on the project.

Don’t shortcut this part of the project. Spend the time to identify the stakeholders who need to be involved, get their input, and thoroughly analyze the requirements (look for contradictions between stakeholders, missing requirements, and so on). For something as complex as an EPMS, you should easily plan to spend several weeks on the requirements depending on the resources available and the availability of the stakeholders.

Dirty Data

Common situation: What do I mean by dirty data? For any data-driven effort, such as an EPMS, to be successful, the set of data to be entered into the system must be complete (you need all the data), the data must be accurate, and the data must be current. If there are inaccuracies in the data (missing data, duplicated data, data errors), the data is considered dirty and should not be used. As database analysts (DBAs) like to say: GIGO (garbage in, garbage out). If one of your selection filters has been programmed with bad data, the impact on project selections can be severe.

Risk impact: While dirty data will not impact the implementation of the EPMS, it could have a significant impact on the output. Bad data will lead to bad recommendations on which projects to select.

Mitigation approach: The majority of the organization’s existing data is often scattered in multiple databases around the organization as well as in individual spreadsheets. There is rarely any quality process for ensuring the data is complete and accurate. Part of the implementation effort will be to identify where all the data exists, clean it up, and transfer it to the new EPMS.

Inadequate Testing

Common situation: When you look at the typical software development schedule, testing and integration are the latest activities on the schedule. This makes perfect sense. But, it means that when the development runs late, the common thing to cut to save schedule over-run is testing. Why? Because testing is almost always on the critical path and cutting testing looks like it might save time.

Risk impact: Cutting testing can be extremely dangerous because you may implement software that has significant bugs in it, resulting in significant cost and schedule impacts due to rework.

Mitigation approach: The only approach to mitigating this is to keep on top of the schedule progress so that if you start falling behind you can recover more easily by crashing the schedule. Never cut testing/integration work.

No Defined Quality Criteria

Common situation: In the press of planning the project and getting the work started, the quality requirements are never developed or not developing in enough detail to be useful.

Risk impact: The implemented system will be not meet expectations and will not be used as designed.

Mitigation approach: Usually, the quality expectations are gradually understood as you go through the requirements gathering process and analyze the nonfunctional requirements. Some of the quality criteria can be quantified, such as query response time and system uptime. But, some of the criteria, such as usability and user-friendliness, are difficult to quantify ahead of time.

The best approach to mitigate the nonquantifiable criteria is to regularly show the steering committee and a user group what they’re getting and to get their feedback as to whether it meets their expectations or not. Communications again! Are you noticing how many areas of the project are improved with good communications?

3.7.4 Risks in Commercial Software

Software does not Meet Needs

Common situation: You bought portfolio management software that does not meet your needs. This occurs when the software’s capabilities are mis-represented by the vendor’s sales people or when there was pressure to purchase a particular package.

Risk impact: The software will not perform as expected, and the money and resources will have been wasted.

Mitigation approach: Carefully identify your specific requirements and select software that meets most of your needs (you probably won’t find software that meets 100 percent of your unique needs) and works in your technology environment.

Don’t trust what the vendors’ sales staff are telling you. Filter the possible software packages down to just a few, then check their user groups to see what people are saying about the software. When you call the vendors in for a best and final presentation, make sure they bring a technical rep who is familiar with the software and prepare a set of detailed questions to ask during the presentation. Finally, video-tape the presentation so that you have a record of what was said (there are two well-known software companies whose salespeople will walk out of a presentation if they know they will be video-taped. Ask around for who they are).

Software too Expensive

Common situation: You’ve found commercial software you want, but the purchasing and licensing costs are well above your budget.

Risk impact: Running over budget.

Mitigation approach: Instead of purchasing the package outright, investigate working with the vendor to use the software on the vendor’s site as a software-as-a-service (SaaS) option or as a cloud-based service.

Contract Poorly Written

Common situation: The contracting person wrote a bad contract.

Risk impact: You find that major parts of the work needed was not included and will cost considerably more.

Mitigation approach: Get involved with the contracting process and ensure that everything needed to purchase, configure, and implement the package was included.

Contractor/implementer cannot do the work

Common situation: The contractor/implementer/consultant who was hired sends in a crew of highly inexperienced staff that are being trained on your project.

Risk impact: The work doesn’t get done on time, within budget, or to poor quality. (This is a surprisingly common problem even with the large, international consulting firms. In their negotiations, they promise you their best available staff, and send you their new hires.)

Mitigation approach: Don’t be afraid to push back and refuse to accept the staff they give you. Your contract should include a clause that gives you approval power over any resumes they offer and veto power over any staff they send.

3.8 Organizing the Project

How you organize the various stakeholders in the project can make the project easy to manage, or extremely difficult. As the project manager, you need to create an organization that supports decision making both for you, for the project sponsor, and for the people who report to you. There are multiple books on organizational theory, but supporting the decision process is really what effective organization is about.

There are two primary parts to creating an effective project organization: the organization chart, which shows reporting relationships, and well-defined roles and responsibilities. The Responsibility Assignment Matrix (RAM) in its various formats and associated role descriptions for each team member are developed during the early planning portion of the project.

3.8.1 Stakeholders During Planning, Design, and Implementation

The project manager should look at the existing resources available within their organization to see what can be utilized on the project. If your organization has a quality assurance department, they should be brought into the project to develop the definitions of quality for the EPMS and monitor it during development. Groups involved in security, privacy, and regulatory compliance should also be involved in the effort as required.

The stakeholders most heavily involved during the planning/design/ implementation effort are:

Other stakeholders will be involved in the requirements and design effort, such as quality assurance support, but as inputs to the development rather than as leaders.

Project Sponsor

The project sponsor is the highest level executive who has direct responsibility for the success or failure of the EPMS. This person is the project’s champion at the executive level. He or she ensures the project gets the priority it needs and appropriate funding and resources. When there is political disagreement at top management levels about the EPMS, the project sponsor leads the resolution efforts. She may also chair the Change Control Board (CCB) for the EPMS project.

Project Manager

The project manager (PM) is the day-to-day lead for the project. The PM heads up the planning effort, ensures the requirements are fully defined, monitors the OCM efforts as well as the design work to ensure schedules and budgets are met. The PM has the core responsibility to make the project successful, regardless of the obstacles that will arise during the effort. The PM sits on the CCB for the project and ensures that quality requirements are satisfied as well as keeping the project on schedule and within budget. Publications by PMI as well as any major textbook in project management can provide much more detail on the roles and responsibilities of the PM.

Steering/Governance Committee

This is the high-level committee that will provide the ultimate approval and guidance for the EPMS project. The project sponsor is a member of this committee as are senior managers of the business units involved in the portfolio selection process. A significant part of the project manager’s time will be spent working with this committee and keeping them updated on the status.

Portfolio Manager

This is the person who will manage the EPMS after it is implemented in the organization. They work closely with the BA to ensure it meets the business needs and in developing the operational processes. They work closely with the technical leads to ensure they understand the underlying architecture and design of the EPMS. They also work closely with both the project sponsor and the PM during the development effort. If the organization has a PMO, most likely, the portfolio manager reports to the PMO.

The portfolio manager may be supported by a portfolio administrator who ensures that during the operational phase of the system that regular status reports are performed, risks are monitored, and other administrative tasks are completed to ensure the system is operating as expected. More about the portfolio manager at the end of this section.

PMO Manager

If there is a PMO within your organization, it is most common for the portfolio management process and tools to be managed within the PMO. The PMO manager and staff should be heavily involved in the development of the EPMS so that it fits most effectively within their organization.

Chief Financial Officer

The CFO or his/her lead staff will get involved in determining the financial filtering criteria to select projects.

CIO and Technical Leads

The CIO is always involved in any project which requires IT resources. They will delegate most of the technical decision making to the technical leads but may be heavily involved in setting priorities and in scheduling of resources and IT activities.

The technical leads (architecture, software, database, and hardware if needed) will be the main decision makers for technical design/development decisions needed to satisfy the requirements. They will be heavily involved in the schedule development and are participants in the CCB as required.

Business Analyst

The business analyst (BA) should be the lead person on developing the business requirements. All of the more detailed technical and operational requirements are derived from the business requirements, so this is a key area for the project. The BA might work together with a process analyst to help develop the operational processes for the EPMS. The BA attends the CCB to identify any impacts to the business requirements or processes resulting from change requests.

Business Unit Managers

These are the heads, or their representatives, of the different business units whose projects will be part of the overall portfolio. They will have an input to the project selection criteria and the EPMS output reports. Their primary interest will be to ensure that projects that are important to them are properly selected. These criteria will need to be balanced out so that the selection process emphasizes projects that provide the greatest benefit to the overall organization, not to individual business units.

OCM Lead

Because the EPMS will create a major change in the organization, the OCM effort will be a significant amount of work to understand the organization’s readiness for the change and to prepare the organization for the new EPMS system. The lead on this effort works closely with the project manager to ensure the organization will be ready once the system is in operations.

Procurement

If the EPMS approach is to procure a commercial product instead of developing one internally, the procurement lead works with the PM, with the BA, and with the technical leads to identify the specific requirements the tool must satisfy and to ensure it is compatible with the existing IT infrastructure.

3.8.2 Responsibility Assignment Matrix

No project should begin without a clear understanding of roles and responsibilities by each participant. This is usually communicated using some form of a RAM along with an organization chart showing the reporting relationships.

One common form of RAM is called a RACI matrix, where each deliverable is listed with who participates in that deliverable and their level of involvement. RACI stands for Responsible, Accountable, Consulted, and Informed.

A more detailed RAM is a “SPIRAL” format, where each deliverable is allocated to the major participants in the project according to whether they:

S—Have sign-off authority

P—Participate in developing the deliverable

I—Provide an input to the deliverable

R—Review the final deliverable for acceptability

A—Are accountable to making sure the work gets done

L—Leads the effort for that deliverable.

Appendix 3.8 has one example of how the responsibility allocations might look. Depending on your organization’s approach, your RAM might be different.

In an effort as significant as implementing an EPMS there are going to be multiple stakeholders, many of them at a decision making level. The primary stakeholders during the development effort should have their roles and responsibilities clearly defined and communicated so they understand exactly how they and everyone else fits into the effort. Initial R&Rs should be communicated during the project kickoff meeting, with more detailed R&Rs defined during the planning effort. During the actual operations of the EPMS, the stakeholders will be different, as we’ll see later.

Critical stakeholders are going to be the executive level. We’re developing an EPMS to select projects that will be most beneficial to the organization based on criteria they select. When done properly, the timeline for selecting strategically important projects will go from a month-long process to a relatively short one because much of the criteria have been automated.

3.8.3 Organization Chart

How should you organize the reporting relationships? The academic answer is to determine the work that needs to be done and the best way to accomplish it.

For business process/IT type projects, the general org chart should look similar to the following, depending on your organization’s normal project approaches:

As the saying goes, your mileage may vary. It depends on how your organization normally does projects. There is an assumption here: the EPMS system will reside in the PMO, and the portfolio lead will be different than the implementation project manager.

Portfolio Manager Redux

Once the EPMS is in place, the most important person in effective operations is the portfolio manager. This is the person who makes the whole system of processes and software run smoothly to provide the inputs upper management needs to make decisions on which projects to put their money into.

Figure 3.8-1 Typical organization chart for IT projects

The specific roles and responsibilities of the portfolio manager will vary with each organization, from a lowly reporting status to having a significant input to the decision process. In a paper¹⁶ published in 2012, academic researchers Aileen Koh and Lynn Crawford from the Bond University in Australia report on the roles of the portfolio manager in a small number of Australian entities.

In one energy distribution company, the portfolio manager reports to a portfolio review board (PRB), which is chaired by the CEO and includes the CFO, CIO, and other senior executives. In the preproject stage, this person is responsible for identifying, categorizing, prioritizing, and evaluating the benefits (using NPV and ROI) of all project business cases for the PRB to select and approve. The quarterly performance of the portfolio is reported to the PRB. After the EPMS was implemented, the IT department alone was able to save 30 percent of their IT project investment budget.

By contrast, in another organization, a financial and insurance company, they report that the head of the portfolio management practice is managed by the head of the strategic IT department. The enterprise PMO is a small organization of only a few people and provides more project management services than true portfolio management processes. So, the roles and responsibilities can vary considerably depending on the needs of the organization.

3.9 Implementing the EPMS

Most articles on implementing portfolio management systems are focused on off-the-shelf software. They describe how to prepare the organization through OCM and make certain that everyone involved is fully aligned with the new system.

Good news! By this point in the book, you have already done the majority of that work—defining management expectations, designing the software and the processes, preparing both management and employees for the EPMS. The only thing left at this point is to “go live.”

At this point, you should have almost everything you need to implement the new portfolio management system checked off, as shown in Table 3.9-1:

So, what’s missing? The detailed strategy for “Go Live” and approval to do so.

Table 3.9-1 Check-off list for project start

1	A high-level project sponsor and a steering committee	√
2	Detailed requirements and expectations from major stakeholders	√
3	An OCM approach to prepare everyone	√
4	A good understanding of the processes to implement	√
5	A good design	√
6	Detailed project filtering criteria	√
7	Selected tools (if you’re buying tools)	√
8	A detailed schedule	√
9	An approved budget	√
10	Defined quality criteria	√
11	A good understanding of the specific risks and a risk management process	√
12	Committed resources, organization chart, and a RAM	√
13	A detailed implementation approach and plan
14	Approval to go ahead and implement

3.9.1 It’s All About the Data

If your team developed the new EPM system, they identified the most efficient database architecture for all the data required. If you purchased an off-the-shelf system, the database is already part of the package, and it may, or may not, fulfill your organizations infrastructure.

As we discussed in the section on risk, the data in your organization is probably spread around in multiple databases, MS Access files, and Excel spreadsheets in multiple different formats and quality. Getting all of this data into the new database is often a major source of problems implementing a new system. All of the project data needed for the EPMS:

The success of the project selection process depends on whether the system has all of the data it needs and the quality of the data. So, this step is critical in the implementation.

Figure 3.9-1 CareFirst existing data locations

Figure 3.9-2 CareFirst existing process interfaces

Combining the data with the processes results in the following complex set of interfaces:

Figure 3.9-3 Complexity of CareFirst data/process interactions

One of their primary goals was to simplify the entire process. After completing the new EPM design the data flow looks like this:

Figure 3.9-4 CareFirst redesigned data flow

In order to gain valuable analysis from all of the data in the EMPS, it is essential that the data structure, the taxonomy, is well defined. This structure is the framework for the data that ensures the data is comparable across different projects and different types of projects.

Métier,¹⁷ which develops enterprise-level portfolio management and optimization software packages, published a white paper titled Implementing Project Portfolio Management, which says: When well defined this way the data can be used in multiple types of analysis, reducing the time required to produce metrics and results. For example, you might want to classify your projects by organizational departments. Without a standard taxonomy, you would only be able to analyze projects that are classified within an individual department, or compare the set of projects between departments.

Frequently, within organizations, there are similar types of projects being conducted in different departments. For example, you may have a “customer satisfaction” project type that occurs in several departments. Using a multidimensional taxonomy, you could analyze the performance and impact of “customer satisfaction” projects across the organization, examine which department performs best on these types of projects, identify duplicative work, or define processes from one department that could be standardized for all “customer satisfaction” efforts. In order to develop the optimal structure for your data, you should take into consideration:

3.9.2 Approaches to “Go Live”

There are three possible approaches to putting the system into production and use.

3.9.2.1 Implement All at Once

This approach, sometimes called the “Big Bang” approach, implements the process, the software, and the filters all at the same time. This approach is strongly discouraged. It has a huge failure rate and can cause the entire effort to be discarded. In 2007, the Los Angeles Unified School District (LAUSD), one of the largest school districts in the United States with over 90,000 employees, hired Deloitte and Touche to completely replace their computer system. They used the big bang approach by deleting the old system before they installed the new system only to find out the new system didn’t work. The problems and lawsuits were massive and dragged on for years.

3.9.2.2 Implement as a Pilot Project

In this approach, the steering committee selects a subset of the organization, such as a divisional IT department, and implements the EMPS only in that organization. If the system also ranks these projects highly, then you can be sure the filters are working. If the system does not rank these projects high, then the filters should be adjusted. From a scheduling standpoint, piloting in one part of the organization should be done for 3 to 6 months to ensure enough data is captured.

Alternatively, the pilot could consist of a few high priority projects and a few low priority projects. If the EPMS identifies and ranks those projects properly, then the filters are working as expected. This approach should only take a few weeks.

These two pilot approaches will tell you whether the filters reasonably reflect what the organization wants to prioritize or whether the filters need to be adjusted.

3.9.2.3 Implement on New Projects Only

Here we ignore the existing projects completely and only input new project requests to the EPMS. As the steering committee meets, they can review the list of proposed projects and agree with the list (in which case the filters are fine) or make changes to the list (in which case, the filters need to be adjusted). This approach may follow the pilot approach mentioned previously. This is a good approach if there is an already-existing queue of projects waiting to be started.

The downside to this is that as long as existing projects have not completed, the portfolio will not reflect the full set of projects in work. Only when all existing projects are done, will all projects be in the portfolio. However, this is a temporary situation and allows people time to adjust to the project requesting process.

3.9.3 Implementation Steps

3.9.4 Improving the EPMS

The incremental approach to fully integrating an EPMS is the best approach, as was already mentioned. Start with a pilot project and build on that. Use the results of the pilot project to advertise the success of the EPMS in identifying and prioritizing the most strategically beneficial projects. This incremental approach is the most effective way to implement the EPMS. Recall in Section 1.4, we discussed the Mayo Clinic’s incremental approach.

Figure 3.9-5 Growth in maturity levels of an EPMS

Many organizations that implement a portfolio management system start off with no recognized or standardized approach to identifying beneficial projects. As the following graphic shows,¹⁸ organizations evolve from a nonexistent system to a fully mature one. By the time you have developed and implemented the EPMS as designed, your organization will be at the “Managed” level with a high degree of maturity. Then it is a matter of additional effort to optimize the new processes.

Step 3 Summary

In Step 1, we prepared the organization for the coming EPMS that would significantly change how projects were selected. In Step 2, we discussed in detail how to design the EPMS to make it as effective as possible, selecting the optimal projects for the organization without any managerial bias. In Step 3, we laid out the details of the project that would be necessary to implement the EPMS.

Project success is frequently determined by how well the project is initialized by the project manager and the project team. Getting the right people involved in developing the project charter and attending the kickoff meeting gets everyone pointed in the right direction, so no one can come along later and state that they weren’t involved early.

Projects live or die depending on how thoroughly the requirements are captured and used to define the scope of work required. Stakeholders are critical in this process, and we discussed how to identify the different types of stakeholders and get them involved. We expended on the work in Step 2 with additional details for the design of the filters.

We then moved into the details of developing the schedule and budget. Both of these begin by identifying the primary parts of the final product and of the project process itself to identify “what” needs to be done. This is the WBS. From the WBS, we can identify the details of the work, the “how” to do it in order to create accurate schedules and budgets. We provided detailed examples of these schedules and budgets that can be used as templates for your own implementations. The more detailed and accurate the schedule, the less likely you are to run into significant problems during the project. For some organizations, internal projects are not subject to detailed budget management. Once senior management has decided to authorize a project, they will continue with the project even if it experiences large cost over-runs. (The project manager may get yelled at, but the project is likely to continue because management is reluctant to waste the time and money already spent.)

We spent a significant amount of time on the project’s risks. Each organization has their own unique risks, but these risks can be categorized into general buckets such as technical risks, personnel risks, poor project processes, and so on.

We moved into organizing the project to increase success—who needs to be involved, who reports to who, who has decision authority, and so on.

We closed Step 3 with a short section on implementing the final EPMS. The process of doing this is so unique to each organization that we could only provide a high-level overview of how to do the actual implementation.

* After teaching project management to thousands of students worldwide, I have seen that no two students or teams will start with exactly the same WBS for a given project. Your own experience, your organizational culture, the current environment will lead to different WBSs. But, in the end, any reasonable WBS will allow you to create a reasonable schedule. If you’ve missed an activity in the WBS, it will show up later on.

^† AACE International 32R-04