Tuesday, June 29, 2010

A Sample Project Mandate Template

<This was created in response to this Stack Overflow question. Apologies for the formatting, it was done in a bit of a hurry and I’ve not had a chance to tidy it up yet.>

I could never find decent project document templates on the web when I went looking for them so I thought I’d post a couple I’ve used recently the event someone else might also find them useful.  They’re sort of PRINCE2 based but I’ve not checked them against the formal definitions so I couldn’t swear everything is in there.

If you do then great, if not then feel free to post your own so they’re there next time someone is looking.

<Project Name> Project Mandate

·         The aim of the mandate is to document findings from the initial project discussions, and to gain agreement on them as a basis on which to proceed.

·         It is not a requirements document however it is common that some potential requirements will emerge during discussion and these should be captured in the relevant sections.

·         All sections in blue are guidance notes which should be removed from the document before circulation.  All sections in italic are examples which should also be removed.

Project Background

·         A 100 – 200 word summary of what the issue or opportunity being addressed.

·         Assume that the reader has a reasonable knowledge of the travel industry, though not that they are an expert in any given areas.

 <Insert Project Background here>

Example:

“TravelSystem is being implemented within Merged Travel Services (MTS) to replace OLDTRAVELSYSTEM (within BigTravel) and Dolphin (within LittleTravel). During the analysis process a number of “gaps” have been identified, including the way TravelSystem handles the BSP (Billing and Settlement Plan) Process. 

BSP is a system designed to facilitate the selling, reporting and remitting procedures of IATA accredited passenger sales agents (see links below for full details).  It is used by both BigTravel and LittleTravel to manage payments to airlines. 

Payments made via BSP need to be reconciled against the appropriate mid-office systems (OLDTRAVELSYSTEM, TravelSystem, Dolphin) to ensure that MTS have not been incorrectly charged.

The aim of this project is to enable TravelSystem to support the BigTravel / LittleTravel BSP process.” 

Project Objectives

·         List the key business objectives of the project as bullet points.

·         They should be unambiguous and where possible stated in numeric terms, even if they are approximate (e.g. “Decrease loading coMTS by 10%” rather than “Decrease coMTS”).

·         If tolerances exist then state them (e.g. if the objective is to reduce the coMTS by 20% but 10% would be an acceptable reduction then state this).

 

·         <Insert Objectives Here>

·         

Example: 

·         Provide a mechanism to update TravelSystem with ticketing details, specifically Ticket Number and Ticketing Date (Project DUNLOP HILL Development Log entry 803-2007).

·         Use this and other details in TravelSystem to reconcile bookings in TravelSystem against the actual payments reported by IATA (Project DUNLOP HILL Development Log entry 803-2612).

Scope

·         “In Scope” should contain details of all elements which have been discussed which are (or can reasonably be assumed to be) within the scope of the project.

·         “Out of Scope” should contain details of anything which has been discussed which will not be tackled as part of this project (but does not preclude them from being addressed at a later date).

·         Focus on areas which will require significant effort or investment, and areas where assumptions are most frequently made (such as performance and security).

·         Where it is not clear whether something is in or out of scope, agree a suitable assumption about it with the Project Sponsor and mark it as an assumption by putting “(Assumption)” at the start of the bullet point.
 

Example:

In Scope

·         Automated import of ticketing details (including Ticket Numbers and Ticketed Dates) from the Galileo GDS into TravelSystem.

·         The ability to rerun imports manually as required.

·         Creation of exception and status reports as required allowing the finance team to monitor the process and resolve issues in an efficient manner.

·         (Assumption) Production of a report to allow FinanceSystem to reconcile the booking information in TravelSystem with the IATA BSP file.

Out of Scope

·         Integration with any GDSs or systems other that Galileo, TravelSystem and FinanceSystem.

·         Tools other than those specifically outlined to allow the finance team to resolve reconciliation errors.

·         (Assumption) Reconciliation with the BSP report produced by IATA itself - FinanceSystem will do this.

Anticipated Benefits

·         List the anticipated benefits the project will deliver if the objectives are achieved.

·         Benefits should be quantified and signed off as realistic and achievable by the Project Sponsor.

Example:

·         Reduce errors in overpayment by £25,000 per year.

Constraints and Dependencies

·         List specific, hard constraints only, not aspirations (e.g. not “The user wants this as soon as possible”).

·         List both the constraint (“Must be live by 1st April 2008”) and the reason for the constraint (“Legislative requirement.”) – the idea is to understand the constraint to see if there are ways of working around it.

·         Where tolerances exist include these (e.g. “Training requirements mean that the system is needed 1 before the legislation comes into force, however if absolutely necessary this could be reduced to 2 weeks”).

·         Also include dependencies on other projects, stating the nature of the dependency.

·         If no constraints or dependencies are known to exist then include the section and simply state that no constraints or dependencies are known to exist.

Example: 

Constraint/Dependency

Reason and/or nature of constraint or dependency

TravelSystem development environment must be in place before analysis and design work can begin.

Access to the TravelSystem database required to understand how data is stored, where and how it needs to be updated.

System must be ready for TravelSystem go live in mid-July.

TravelSystem can not go live if BSP reconciliation can not be carried out and TravelSystem should not be delayed.

Quality Expectations (optional section)

·         If included this should list any specific quality measures that have been identified, avoiding general aspirations (e.g. “As this is a financial system quality is paramount”).

·         This may include things such as performance or volume levels or acceptable error rates.

·         Where known thresholds exist these should also be stated.

·         Where it is not clear whether something is or is not a quality expectation (or precisely what it is), include it with a “best guess” measure and mark it as an assumption by putting “(Assumption)” at the start of the bullet point.

Examples:

 ·         100% of records must either be handled correctly or promptly reported in an unambiguous and controlled manner. 

·         It is anticipated that no more than 5% of records should be exceptions (and therefore require manual intervention by either Finance or IT staff) under normal circumstances.  The absolute maximum threshold is 10% of records being exceptions.

Project Team and Interested Parties

·         The following roles should be identified:

·         Project Sponsor – the ultimate decision making authority on the project, usually the owner of the budget

·         IT Owner – the member of the IT team who is owning the project (not necessarily the project manager – this is the person responsible for looking after the provision of IT services, not managing the whole thing)

·         Senior User – the individual responsible for providing user input and detailed requirements.  Often the executive won’t specify precise requirements themselves, instead passing this responsibility to someone else within their team who has a more detailed day to day knowledge.

·         Each of these roles should be filled by one person.  In the case of senior user and senior supplier the role may be split between two in some cases, however there should only ever be one executive. 

·         In addition other parties with a significant interest should be identified and listed, along with their role (which should indicate why they’re interested).

The following have been identified as the likely key individuals on the project:

Project Sponsor: Short Person (DUNLOP HILL Finance Stream Leader)

IT Owner: Really Annoying Person (MTS IT)

Senior User: Useless Person (MTS Finance)

The following interested parties have been outlined:

DUNLOP HILL Project Manager: Waste of Oxygen Person

Head of Project DUNLOP HILL: Nice Person

MTS IT Development Manager: Me

Additional Information

·         Provide any additional information which will be of use including links to documents or websites.

·         Keep information relevant, not just general, aspiration comments (e.g. not “the user would like this as soon as possible”).

Example:

http://www.iata.org/ps/financial_services/bsp/ 

http://www.iata.org/ps/financial_services/bsp/how_bsp_works.htm 

E:\Business Analysis\Project DUNLOP HILL\Systems\TravelSystem (BadTec)\HH&TL\Detailed Discovery\Development & Issue log.xls

Version History

8th April 08 - 0.1 Draft - Me - Issued for circulation

9th April 08 - 0.2 Draft - Me - Revisions following Really Annoying Person comments