Requirements : Horizon PPM

Introduction

The project's Requirements set the background and context of the background. In HORIZON PPM we ensure the Requirements are visible to all project participants to provide guidance when making decisions in every day project matters.

Project requirements are often documented at the start of a project to help set the direction, but they can also be updated intra-project to accommodate new requirements by changes in delivery of the original plans or external influences.

Note: It is common for material changes in requirements to be subject to a project control review - not least of which would include an approval of the changes by a Steering Group. Due to the difference of approaches to project change control across organisations this is outside the scope of HORIZON PPM.

Accessing Objectives

Requirements are also accessible from the left-hand side navigation bar...

Requirements can also be access via the counter for Completed Objectives on the Project Home. Clicking the counter navigates to the Objectives home.

This page has two tabs allowing a user to toggle between Objectives and Requirements

See the Objectives help page for more information.

The Requirements

The Requirements should be documented under the different tabs for each of the different sections

Each of the sections is a free text area able to accommodate as much or as little text as the user requires.

The sections provided are...

Project Overview

The project overview provides a summary view of the project and it's high-level purpose. This text will be automatically added to the project status report as well as the project definition document.

Business Case

The business case should provide the rationale or justification with the benefits to be realised by the project. Direct/tangible benefits can include increased revenues (via sales) or reduced costs (through improved operations). A range of indirect/intangible and non-financial operational benefits includes...

Maintain/Protect revenue/market share
Reduce risks
Avoid costs
Improve customer satisfaction
Grow customer/user base (without growing revenues)
Expand marketing reach
Exploratory R&D
Platform for future initiatives
Power and influence
Increase capacity
Improve stability
Improve control
Improve security
Address regulatory, compliance or audit requirements
Operational processing or organisational efficiencies

Benefits should be qualified and quantified to help compare against the project costs to achieve them.

Scope

The scope should include what is In Scope and what is explicitly Out of Scope of the project. Having a clear scope removes any ambiguity over what is being delivered. An alternative to listing everything out of scope is to use a statement such as "Anything not explicitly recorded as in scope is implicitly considered out of scope".

Approach

The project approach provides guidance on how a project is expected to be delivered. This could include providing direction on doing things in-house or using specialist suppliers; breaking a project into different work streams; or setting checkpoints at certain stages to ensure the project is still in track to meet the desired objectives.

Constraints

The constraints provide known or expected restrictions, limits and/or deadlines at the outset of a project. They come in many guises and can include availability of vendors or key resources; fixed deadlines; financial restrictions such as budget periods, funding tranches, foreign exchange rates, etc. Constraints are often tracked as individual RAID items during the project delivery.

Opportunities

Not all project change is negative. Stretch targets or other potential opportunities that are already identified or could emerge during the life of the project should be documented here. These opportunities may not directly match the project's stated objectives and benefits case, but beneficial to the organisation in other ways - such as cost savings through decommissions could also improve an unstated ESG goal of reducing carbon emissions.

Quality & Test Strategy

The Quality & Test Strategy should include details of the people, process and tools to be used to provide ensure the quality of the outputs of the project, along with details on the project assurance mechanism to ensure the project itself is being managed in accordance with organisational policies and best practices.

Communications

Outline the people, process and tools to be used to provide keep the various stakeholders informed during the life of the project. Communication can be either one-way (broadcast) such as newsletters and web sites, or two-way (collaboration) in meetings or calls. Where appropriate include the tolerance parameters and the "break-glass" plans for managing exceptions.