The ultimate success of your project will depend on resolving the issues and risks associated with implementing a PPM process and solution in your organisation as well as quantifying benefits and savings.  You need to be sure that the chosen solution is fit for purpose and will solve business issues - not add to your problems!  You need to ensure that the benefits and savings will work in various aspect before you procure and implement the system.

Typical areas to address include:
Technology
· Does the proposed system run fast enough?
· Will it require additional infrastructure?
· How easy will it be to transfer data?
· Does the software interface with existing systems?

Culture
· Will people find the new system easy to use?
· Does the system use familiar terminology?
· How does the system fit with existing or proposed procedures?
· Where does it fit within your project management maturity environment?

Answering these questions using traditional evaluation techniques can be difficult and proactive management of risk is vital.  Since PPM deployment is a change management project we recommend implementing a project based risk management framework.

Within the framework we establish possible events or circumstances that may have a negative effect on the project and put in place a contingency plan to reduce or eliminate the risk.

Some factors that need to be taken into consideration

· Description – the nature of the risk
· Precautions – consider what can be done to mitigate the risk
· Consequences – the possible effects if the risk occurred
· Identification – choosing unique identifiers for referring to the same risk in company or project documents
· Risk status – classification as new, ongoing or closed
· Risk escalation  - estimating the probability of the risk becoming a liability
· Schedule impact – estimating the consequences in terms of time/budget for the project

In order to manage project based risk it is essential that a risk management plan is drawn up for the project and that specific responsibilities are allocated for activities and tasks. Moreover the project risk database must be kept up to date and reviewed regularly to ensure that it takes account of any changes.

Establishing Proof of Benefit

What is Proof of Benefit?

A proof of benefit (PoB) is in effect a configurable test environment that enables the business to understand from a real-world perspective how PPM will be delivered to the business. The PoB brings together the software application and processes into one single environment. The software side of the PoB can be hosted as part of a SaaS offering which will obviate the need for an internal server installation and reduce costs and timescales.

The PoB exercise will involve:

Developing and agreeing PoB objectives and scope
Agreeing the issues concerning the existing status of the current processes such as:
time recording
milestone management
project management
resource management
management information production
scenario and project modelling
Agreeing the framework for delivery of the PoB around areas where the business can develop a PPM model and deliver it into the business
Assessing and testing the PPM model and delivering the results back to the business

A PoB Step Process

A PoB will typically involve the following key steps:
Step 1 Objectives and Goals
Step 2 Principles and Scope
Step 3 ‘Current State’ Assessment
Step 4 ‘Future State’ Assessment
Step 5 Gap Analysis Assessment
Step 6 Presenting the Results to the Business

ROI/ROO Analysis

The rationale behind any project carried out by a commercial organisation should be either to deliver cost savings, or an improvement in revenues, or both. However, it is only effectively managed projects that retain a link to strategic initiatives that can deliver on the above. Cost savings can either be delivered by a reduction in headcount, or savings gained through efficiency improvements can be used to enhance customer service, vendor management, or less tangible activities such as training, mentoring and the like.

This type of quantitative, financially based requirement for return is a very compelling driver for change, yet is only part of the overall picture when looking at both potential tangible and intangible benefits. Therefore return on opportunity (ROO) analysis helps organisations define and quantify potential top line benefits from deploying new business processes, including in respect of revenue, market capitalisation, an increased customer base and decreased attrition. ROO analysis is most effective when it crosses departmental boundaries, integrates disparate capabilities and provides capabilities that an organisation did not have or had not addressed before.

Using an ROI/ROO calculator model is an effective way of measuring the organisation’s key project and programme cost and time data to identify potential cost savings over five years.

Building an ROI/ROO model

Once the stakeholders have identified the common activity conducted within their control and understood the percentage split and breakdown of activity, time efficiency calculations can be made to identify the potential ROI and subsequently the ROO that are achievable. This is simply based on time savings against the ‘now status’ way of working and processes. These can be compared with representative savings once PPM has been implemented and adopted through an effective change programme.

Research has demonstrated that work practices without a PPM solution in place can incur a workplace productivity wastage of as much as £650 per person per month, which in turn could represent an annual wastage, within a department of 100 staff, of approximately £780,000. It is important to note that enterprises rarely cull people, but rather move savings into value creation activities such as a new or different corporate initative.

These are the steps that need to be followed:

1. Step 1: Work days and staff costs
2. Step 2: Project/programme related activity costs
3. Step 3: Calculating potential ROI
4. Calculating potential ROO

The health check is conducted in cojunction with the selected vendor, is the first step in assessing the needs and requirements of the business, and is designed to be a low risk engagement model. The health check allows the business to analyse key processes underpinning the delivery of projects within the organisation in order to make certain that the solution and process will deliver value.

A typical health check exercise includes:

• Review of a number of agreed key processes, typically including:
  - portfolio management
  - management reporting
  - project resourcing
  - milestone/delivery reporting
  - scenario modelling
  - project/programme management
  - time recording
• review of document processes, including inputs/oututs and data flows
• identification of timings for processes
• understanding and documentation of business issues and constraints

Identifying the need for PPM comes from understanding how the business operates, its projects management maturity level, and the processes used.

The overall objective of any PPM process is to balance project investment and expenditure across the business so that the enterprise can quickly make decisions around trusted information, aiding the change of direction within the business. In other words, the purpose of PPM is to enable the enterprise to identify projects not aligned with agreed strategy, and redirect resources to other value creation activities within the strategy. Therefore a key component of developing the initial business case is providing a breakdown of business-as-usual activities compared with project-centric activities. Doing so will allow key sponsors to understand strategic alignment issues and those projects that provide value to the corporate strategy and objectives. Management’s goal should be to break up the investment into pots of tactical spend to support the strategy, making sure the spend is correctly directed into strategic value and stakeholder value coupled with shareholder value.

PPM should be delivered into the business as a change management project. The business case needs to explain how the scope of the proposed PPM project fits within the existing business strategies and develop a compelling case for change, in terms of the existing and future needs of the organisation. The business case then needs to balance the costs, benefits and risks of delivering PPM. It needs details of proposed commercial arrangements; a cost/benefit analysis ideally including analysis of ’soft’ benefits, in other words those that cannot be qualified in financial terms; preferred options and any trade-offs. Also needed is an assessment of affordability and available funding linked both to proposed expenditure and to available budget and existing commitments.

The business case also needs to address ‘acheivabilit’. It needs to set out the actions which will be undertaken to support the achievement of intended outcomes, including procurement activity such as the purchase of consultancy and software. This is supported with a plan for achieving the desired outcome, identifying the key milestones, dependencies, roles, contingencies, risks, skills and experience required.

Therefore the typical business case will take the following form:

• strategic objectives and scope
• benefits realisation
• resources required
• cultural impact
• revenue/savings
• capital and operating costs
• timescales
• appraisal

The development of any business case needs to address the following key issues and calculate their potential ROI and benefits:

• People, process improvement and productivity
• Profitability
• Performance
• Customer/partner satisfaction
• Management information

With the initial RFI under way, a detailed list of requirements can be built up, supported by the business case and ROI model. Although meeting all the main requirements is important, it should not be the deciding factor in vendor selection. Some vendors will be able to do everything, but superiority in implementation times, costs, software functionality and process restrictions may outweigh the value of some of the other requirements. Often a detailed requirements capture is designed to understand everything available but is then mistakenly used as a bible to which all vendors should adhere. This mistake may cause software featureand process bloat, meaning that gainig actual value will be difficult and the implementation will fail. Look at the key areas of the ROI, assess which parts of the software solution and business process add most value in relation to each vendor, then a best fit across all the variables can be found. The most balanced vendor for your business needs will rarely be the one with all the bells and whistles.

Key areas to address when reviewing a vendor as part of a RFI are:

• methodology support
• process enforcement
• whether an evaluation budget is required
• whether the software is functionally supported
• integration (financials, billing, HR, and so on)
• the vendor’s experience in the sector (IT, PSA, engineering, construction, and so on)
• the vendor’s core values, parent company, and so on
• the business case for the solution in general and for each vendor
• ROI and ROO projections for each vendor
• feature functionality: whether the vendor promotes ‘bells and whistles’ or demonstrates core strengths that will add long term value to the business
• strategy: how the vendor sees the future of their technology, and business process enforcement methodologies
• where the vendor’s solution comes from, how much time they have spent on it, and so on
• how the vendor’s customers are supported at every stage of a partnership
• culture: whether the vendor is customer focused, part of a sales organisation, part of a PLC
• whether the vendor can provide customer references relevant to your business
• track record: where the vendor’s strengths lie. their history of successful installations
• market position: whether they are market leaders, have an extensive product-set, whether PPM is a core part of their business
• partnership strategy: whether they treat the customer as a sale or more of a development partner working towards a best-of-breed solution
• focus and vision: where the vendor’s focus lies in relation to their products and their future
• value added after implementation: whether they will leave, or work with you to continuously improve and develop the solution for the business

Once an understanding of the business has been developed, the processes and demands can be mapped onto the requirements process. It is at this initial stage that high-level stakeholders should be brought into the process. The requirements capture process shoudl itself be high-level, with a more detailed analysis done once a better understanding of what is on offer has been developed. The requirements capture process should involve the following key steps:

1) Determine requirements scope and objectives
2) Decide on the requirements gathering model or methodology
3) Identify the key project stakeholders
4) Build the requirements model
5) Gather project stakeholder needs and information
6) Create a requirements specification, consisting of:
     - business and process requirements
     - people and resources requirements
     - capabilities and functional requirements
     - review infrastructure/IT architecture
7) Test, review and verify the requirements specification
8)Build the requirements into an RFI

In order to ensure best practice the following key considerations should be factored in:

• ‘Translate’ technical language into business language and vice versa
• Ensure stakeholder involvement at all levels of the process
• Draft clear and concise written documentation for all types of stakeholders
• Ensure that the requirements are quanitifable and measureable
• Ensure that the requirements are clearly defined in the vision and scope document
• Prioritise requirements by their relevance importance
• Verify the completeness of the requirements by formally inspecting the documents generated
• Identify and remove any software functionality and process steps that do not meet any of the business objectives
• Establish and enforce a clear and realistic process for change management
• Analyse risks to avoid unforseen complexities and slippages

The requirements should then be used in a preliminary request for information (RFI), typically sent to a selection of consultants and software vendors. Once the consultants and vendors have demonstrated their ability to meet a broad range of needs (any that do not meet the basics can be removed, leaving a shortlist) then the next stage is to further define the requirements in order to build a solid business case. While moving forward with the selection process there are a number of things to consider both concerning the business and while reviewing the vendors. Each vendor will take a slightly different angle on the processes and solution for implementation, which will generate value in different areas of the business. Reviewing where the biggest issues lie and who is best suited to delivering on these issues will aid in reducing the shortlist further. Without the understanding and evidence of the business case and ROI, a vendor selection many not be possible. Allowing each vendor to put forward information to gain the buy-in of the stakeholders will reduce the probability of failure later in the project.

When implementing a PPM process it is best to keep in mind the following key questions:

• Executive sponsorship: Are we going to get executive support to implement a Project Portfolio Management process? Will we get adequate funding, people and time to implement this?
• Culture and organisation structure: How flexible are the staff, can they change their existing mind-set as well as business processes?
• Project management and business processes: How do we tie our strategic objective to project deliverables, and what will be the impact of PPM on our existing business processes and project management infrastructure?
• Metrics and performance criteria: Have we established realistic, measurable performance criteria? What will be our ROI and ROO models?
• Quick wins and credibility: How do we ensure that we get quick wins and quick ROI? How do we ensure that PPM is taken seriously as a change management project? Are our resources going to provide us with the right inputs to go into the PPM infrastructure?
• PPM staff and experts: Will we have internal or external PPM experts who can manage the whole process of PPM evolution in the organisation, that is, selecting a PPM vendor, establishing success criteria, taking alternative actions if PPM implementation does not go as planned, and monitoring vendor artefacts and processes?
• Technology: Are our staff technically minded enough to use the software to its utmost capacity?

Having understood the relevant issues that need to be addressed in order to start organising the business for PPM, we now need to translate this into reality.

Determining the location of the business’s ‘domain’, or in other words, where to deploy the initial PPM process, is critical. Depending on your level of project management maturity, the higher up the organisation the process is to be deployed, the more challenging its implementation will be. The proof-of-benefit (PoB) process discussed later within the chapter articulates the need to prove the initial ROI at a more tactical level within the business, typically at the unit or departmental level. The rationale is to enable the business to construct, test and model the PPM process within a low risk environment as well as understand the change management issues confronting the organisation. Beyond this, the business case built around the PoB is deisgned to enable the business to roll out the PPM process to other parts of the business.

To de-risk the process of organising and deploying a PPM solution, it is essential to deal with ‘chunks’ of activity that prove the value of the solution and process from one stage to the next. Very rarely will a business have all the necessary internal skills to deploy a PPM process. Therefore, to deliver successful PPM and also to strengthen any exisiting in-house expertise, it is recommended that the organisation be in position to recruit outside help in the form of professional consultancy services and software application vendors. We will outline the necessary steps involved in recruiting outside expertise, then we will go into how the business can kick-start the process.

The main areas for consideration include:

a) readiness assessment
b) requirements capture
c) vendor selection process
d) business case considerations
e) the health check
f) measuring the return on investment (ROI) and return on opportunity (ROO)
g) establishing proof-of-benefit (PoB)
h) building a risk management framework.

Understanding the business case through to rollout within the enterprise requires that a number of stages to be followed. Developing an ROI model, understanding the requirements, processes and demands involved, then putting in place a PoB all count as part of the due diligence needed for a successful implementation.

A the process progresses more detail is added to the business case, as when vendors are selected and a roadmap put in place the ROI model becomes clearer, scope changes, opportunities arise or new initiatives are derived from the initial idea.

Next week, we will provide more detail on each area for consideration in the above list.

Not all projects make the grade and many need to be eliminated even after the portfolio has been approved, because:

a) The projects concerned do not provide sufficient value and are no longer aligned with the business’s objectives.
b) Projects with a higher urgency have been proposed, resulting in a delay to or termination of current projects.
c) A project has been rescoped and integrated within another.
d) Technology has changed, negating the benefits of a planned project.

With only a small percentage of the proposed projects approved and executed, it is crucial that they succeed. Since the business is changing throughout the year, there will also be ongoing changes to the portfolio. This includes the addition of new projects and the elimination of old. This ongoing process of replanning and rebalancing the work, based on changing business needs, is also a part of the portfolio management execution and monitoring process. Portfolio management is therefore more than a one-time event that is performed once a year during your business planning phase. It is a contiual, iterative process that needs ongoing monitoring and course correction. It is essential that the PPMT take proactive steps to resolve problems and keep projects on track by:

a) correcting overlaps and redundancies
b) reviewing and resolving issues and problems
c) monitoring project spending and adjusting budgets
d) monitoring and mitigating project risks
e) managing resource conflicts sch as supply and demand shortfalls
f) reassessing the timing and duration of projects

The PPM selection and prioritisation process is easily emasculated if the portfolio is not actively managed. With projects straying over time, over budget and with business goals shifting and evolving, even originally well conceived projects rapidly become misaligned. However, misalignment must not be feared; it is in fact a natural and expected outcome. The real success of PPM lies in the ability of the PPMT to identify this misalignment and take corrective action. The PPMT must be able to make objective ‘go/kill/hold/fix’ decisions and be able to recognise that a dramatic change in business priorities may eliminate the need for a project, requiring quick project terminatio. As stated earlier, management of the portfolio includes managing the resources, proactively communicating what is going on, reviewing and replanning the remaining work on a regular basis and measuring the results. If new projects are added to the portfolio it will mean that other, previously authorised projects will need either to be eliminated or put on hold. With the help of the PMO, the PPMT needs to document and track individual projects and impelment a course correction process to ensure that the portfolio as a whole accomplishes its objective.

The typical steps involved in executing and monitoring the portfolio include:

Step 1: Gathering project portfolio information
a) collective individual project score cards
b) building a consolidated portfolio score card
c) collecting  project and portfolio resource plans including shortfalls and new demands
d) building a detailed project status report
e) building a detailed portfolio status report

Step 2: Measuring and analysing the project portfolio
a) measuring the performance of ongoing projects
b) measuring the success of completed projects
c) measuring interdependencies between projects
d) measuring overall business value and alignment
e) determining an inventory of projects for portfolio course correction changes

Step 3: Analysing the impact of changes to the project portfolio
a) analysing the impact of projects that may be cancelled
b) analysing the impact of newly identified projects
c) analysing the impact of current projects not achieving objectives
d) analysing the impact of projects that have changed their scope

Step 4: Reviewing portfolio changes and reforecasting
a) filtering new projects against the existing project portfolio
b) reviewing current and new portfolio goals and objectives
c) ensuring individual project business cases are revalidated and aligned with these objectives
d) ranking projects against revised priorities
e) updating the project inventory
f) modelling resource scenarios and analysing the overall impact on the business
g) selecting scenarios and updating the resource schedule

Step 5: Communicating and implementing portfolio changes
a) revalidating business cases for existing authorised projects
b) revalidating business cases for newly authorised projects
c) issuing a new project portfolio review
d) providing guidance on changes to portfolio work
e) communicating with project stakeholders
f) agreeing a timeframe for the next portfolio review
g) making ‘go/kill/hold/fix’ decisions

Being able to take corrective action on projects is a key component of PPM. If a project is not meeting its objectives, it is crucial to identify the root cause, develop an action plan, and then monitor and track to ensure the action is implemented and the issue is resolved. The PPMT must have the ability to intimately understand how projects in the portfolio relate to different business goals and the ramifications if either projects or business goals change. The PPMT needs to track trends and anticipate new opportunities and threats so that project stakeholders can implement measures to avoid misalignment.