Programme and Project Portfolio Management Blog (PPM)

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 gaining 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

Seven resaons why IT projects fail.

1. Poor or undefined project objectives, roles and responsibilities, leading to unrealistic expectations being set.

2. Lack of communication between IT and the business, resulting in a mismatch of requirements and expectations.

3. No senior business sponsor and separate project manager.

4. Technology put before people: no or minimal involvement of key users during the “scoping” phase and lack of regular communication with them throughout the project implementation

5. No project sucess metrics.

6. No risk assessment or contigency plan.

7. Lack of regular checks to ensure the project is on track – to time and budget.

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 should 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.