LATEST POSTS

Business case considerations

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

Vendor Selection Process

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

Requirements capture

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.

Readiness Assessment

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?

Where to deploy PPM

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.