Preparing Your Project for Submission to the Portfolio Management Process
,Now that you understand the portfolio management process, you should have a pretty good idea of what you need to do to prepare your project proposal for submission and consideration as part of a portfolio. Your organization may require you to follow a prescribed procedure for proposing your project. If not, I suggest that you prepare your project proposal in one of the following ways:
- Adapt the POS, which was discussed in detail in Chapter 4. The POS will work quite well but may need some additional information, such as cost and time estimates, that is traditionally not part of the POS.
- Try a two-step approach. Submit the POS first to determine the alignment of your project, and then prepare a detailed project plan to submit time and cost data to the prioritization and selection phases.
- Develop an entirely new submission process based on the five-phase portfolio management process.
The next three sections describe each one of these options.
A Revised Project Overview Statement
As discussed in detail in Chapter 4, the POS is a short document (ideally one page) that concisely states what is to be done in the project, why it is to be done, and what value it will provide to the organization when completed.
When it is used in the portfolio management process, the main purpose of the POS is to have the portfolio committee evaluate the project and determine whether it is in alignment with the corporate strategy. Later, it will be reviewed by the managers who are responsible for setting priorities and deciding what projects to support in the portfolio. For this reason, the POS cannot contain any technical jargon that generally would not be used across the enterprise. Once approved, the POS becomes the foundation for future planning and execution of the project. It also becomes the reference document for questions or conflicts regarding project scope and purpose.
Parts of the POS
The POS has the following five component parts:
- Problem/opportunity statement
- Project goal
- Project objectives
- Success criteria
- Assumptions, risks, and obstacles
Recall that its structure is designed to lead the reader from a statement of fact (problem/opportunity) to a statement of what this project will address (project goal). Given that senior management is interested in the project goal and that it addresses a concern of sufficiently high priority, they will read more detail about exactly what the project includes (project objectives). The organizational value is expressed as quantitative outcomes (success criteria). Finally, a summary of conditions that may hinder project success are identified (assumptions, risks, and obstacles). The following list looks at each of these parts more closely as they apply to the project portfolio process:
Problem/opportunity statement — The first part of the POS is a statement of the strategic objectives that the project is addressing. If appropriate, the statement should come directly from the company's strategic plan or be based on the portfolio strategy. This is critical, because it provides a basis for the rest of the document. It also sets the priority with which the portfolio manager will view what follows. If you are addressing a high-priority area or a high-value area, your idea will get more attention and the reader will read on.
Project goal — The second section of the POS states the goal of the project: what you intend to do to address the strategic objectives identified in the previous section. The purpose of the goal statement is to get senior management to value the idea enough to read on. In other words, they should think enough of your approach to the corporate strategy to conclude that it warrants further attention and consideration. Several other proposals will pertain to the same objectives. Because yours will not be the only one submitted, you want it to stand out among the crowd.
The goal statement must not contain any language or terminology that might not be understandable to anyone having occasion to read it. In other words, no techie talk allowed. It is written in the language of the organization so that anyone who reads it will understand it without further explanation from the proposer. Under all circumstances, avoid jargon.
Keep the goal statement short and to the point. Keep in mind that the more you write, the more you increase the risk that someone will find fault with something you have said. The goal statement does not include any information that might commit the project to dates or deliverables that are not practical. Remember that you don't have much detail about the project at this point.
Project objectives — The third section of the POS presents the project objectives. Here is your chance to show more breadth to your project and bind it even tighter to one or more of the strategic objectives.
Success criteria — The fourth section of the POS answers the question “Why do we want to do this project?” It is the measurable explicit business outcome that will result from doing the project. It sells the project to the portfolio manager. This may be the most important part of the POS. The portfolio manager is trying to maximize the value that can be generated from the portfolio. Every project has to contribute to that value.
The question that you have to answer is this: What business value will result from successfully completing the project? The answer to this question will be a statement of the explicit business outcome to be realized. It is essential that the criteria be quantifiable and measurable, and, if possible, expressed in terms of business value. Remember that you are trying to sell your idea to the portfolio manager.
As an added value statement, consider quantifiable statements about the impact your project will have on efficiency and effectiveness, error rates, reduced turnaround time to service a client request, reduced cost of providing service, quality, or improved client satisfaction. Management deals in deliverables, so always try to express success criteria in quantitative terms. By doing this, you avoid any possibility of disagreement later as to whether the success criteria were met and the project was successful. The portfolio manager will look at your success criteria and assign organizational value to your project. In the absence of other criteria, this success criteria will be the basis for his or her decision regarding whether or not to place the project in the portfolio.
Assumptions, risks, and obstacles — The fifth section of the POS identifies any factors that can affect the outcome of the project and that you want to bring to the attention of the portfolio manager. These factors can affect deliverables, the realization of the success criteria, the ability of the project team to complete the project as planned, or any other environmental or organizational conditions that are relevant to the project. Record anything that can go wrong. Be careful, however, to put in the POS only those items that you want senior management to know about and in which they will be interested.
The project manager uses this section to alert the portfolio manager to any factors that may interfere with the project work or compromise whatever contribution the project can make to the organization. Do not assume that everyone already knows what risks and perils to the project exist. Document them and discuss them.
POS Attachments
The best way I have found to provide the important time and cost information with your POS is through one or more selected attachments. As part of their initial evaluation and prioritization of your project proposal, portfolio management may want some measure of the economic value of the proposed project. They recognize that many of the estimates are little more than a guess, but they will nevertheless ask for this information.
I recommend giving range estimates rather than point estimates. You don't have enough detail at this point to do any better.
In my experience, I recommend that you consider adding one of the following two types of analyses to your POS:
Risk analysis — In my experience, this is the most frequently used attachment to the POS. In some cases, this analysis is a very cursory treatment. In other cases, it is a mathematically rigorous exercise. Many business decision models depend on quantifying risks, expected loss if the risk materializes, and the probability that the risk will occur. All of these are quantified, and the resulting analyses guide the portfolio manager in decisions on project approval. Risk management is discussed in detail in Chapter 3 and briefly in Chapter 4.
Financial analyses — Some portfolio managers may require a preliminary financial analysis of the project. Although such analyses are very rough because not enough information is known about the project at this time, they will still be useful. In some instances, they also offer criteria for prioritizing all of the POS submissions that the portfolio manager will be reviewing. Some of the possible analyses are feasibility studies, cost/benefit analyses, and breakeven analyses. These are all discussed in Chapter 4.
A Two-Step Submission Process
The first step in the two-step submission process is to submit the POS as described in the previous section. Once the alignment decision has been made and the project is aligned with the portfolio strategy, the second step can be taken. The second step is to prepare and submit the detailed project plan. The plan can contain information that would be useful for later decisions, but this information is generally not provided unless it will be used. The strategy in the two-step process is to do the extensive planning work only if the project is deemed to be in alignment with the portfolio strategy. An added benefit to the two-step process is that how the project is aligned may also be useful information for the planning work. In my experience, the planning effort can take a number of directions, and knowing specifically how the project relates to the portfolio strategy can produce better and more targeted business value.
A New Submission Process
If you are going to fashion a new submission process based on the five-phase portfolio management process, I advocate a single submission that contains all of the information needed to take the project up to the SELECT stage of the project portfolio life cycle. What information is needed to reach that point? Here is a list for your consideration:
Project name — This should be a name that provides some indication of what the project is all about. Don't use code names like XP.47.
Sponsor name — This is the name, position title, and business unit affiliation of the sponsoring individual.
Project manager name — Add this if known.
Project funding category — This will attach the project to some part of the portfolio strategy. In some cases, multiple categories may be given.
Project goal — This will be the same type of statement you would have used in the POS for this project.
Project objectives — This will be the same type of statements you would have used in the POS for this project.
CASE STUDY — PIZZA DELIVERED QUICKLY (PDQ)
The entire PDQ project could be viewed as a program consisting of several dependent projects. Once the component parts of the project have been identified through the initial changes, including those introduced by Dee, the project might be represented as shown in Figure 14-22.
If one views this as a program consisting of six projects – one for each subsystem – there are a number of ways to approach finding the solution. The Order Entry and Inventory Management subsystems should be available as commercial off-the-shelf products. A Request for Information (RFI) or Request for Proposal (RFP) can reach that conclusion quickly. The other subsystems are quite different. All four require some form of heuristic algorithms as part of their solutions. The difficulty with each of these is that order preparation can be at one of three sites. The stores and the pizza factories are fixed in place, whereas the pizza vans are moving locations. The same moving location problem complicates the Routing subsystem. So these four subsystems are highly interdependent, and an optimal solution may not be possible. That is why a heuristics approach may be the best approach.
As far as a portfolio approach is concerned, this could be viewed as two separate submissions. One would be for the Order Entry, Order Submit, and Inventory Management subsystems. Together they provide an operational solution for the current store situation. The other would be the Logistics and Routing projects that deal with the complexities added by one moving component – the pizza vans that prepare pizzas and that can also deliver pizzas. Even that solution could be done in stages. The first stage would incorporate the pizza factories as just another fixed location for preparation. The second stage would add the pizza vans as moving preparation locations. The Adaptive Project Framework (APF) works well regardless of the approach taken.
Figure 14-22: Systems-level solution for PDQ
Explicit business value — This is a very important piece of the submission. Here you have to establish the business value for this project. Make a quantitative statement about increased revenue, decreased cost, or improved service. It must be a measurable metric.
Risks — When combined with project cost and explicit business value, this gives financial analysts the grist for their mill. This is where the true business validation of the project is made or lost.
Estimated total project cost — You do not have a detailed project plan at this point, so all that you can give is a range estimate.
Estimated project duration — You do not know when the project will begin, so you cannot give a completion date. The statement you want to make here is something like, “This project will be completed eight months after the start date,” or even better, “This project can be completed in six to nine months following its start date.”