Project Brief

This template is a sample template from the ProGo Template Library including template, guidelines and example. ProGo is a registered Trade Mark of Common Vision Pty. Ltd.

The example provided within this template is fictitious and is provided for the sole purpose of illustrating template usage.

The suite of ProGo suite of over 70 IT templates (incorporating a consistent example across all templates) can be purchased with the ProGo Professional Environment from www.myprogo.com

[Company Name] [Company Logo]

Project Brief

[Project Name]

Document Id: [Document ID]

Document Version: 0.1

Author: Project Manager

Document Status: [Draft/Final/Released]

Release Date: [Date]

Location: [Document Repository]

http://www.myprogo.com/

document.doc

Document Approval

Name Signature Signoff Date

Case Business(Project Stakeholder)

Reviewer

Jason Driver(Project Manager)

Author, Owner

Joe Assurance(Quality Manager)

Reviewer

Mike Direct(Team Lead)

Reviewer

Mr. Big Picture(Architect)

Reviewer

Nance Governor(Project Board Member)

Approver, Reviewer

Version 0.1 Modified 20-Oct-08

Status [Draft/Final/Released]Page 2 of 20

ProGo Template www.myprogo.com

Copyright 2007 Common Vision Pty Ltd


document.doc

Document Contents1 Introduction............................................................................................................................4

1.1 Purpose..........................................................................................................................41.2 Audience........................................................................................................................41.3 References.....................................................................................................................4

2 Project Mandate.....................................................................................................................52.1 Project Sponsor.............................................................................................................52.2 Project Management Appointment.................................................................................52.3 Background....................................................................................................................62.4 Business Case Summary...............................................................................................72.5 Expected Outcomes.......................................................................................................8

3 Project Description.................................................................................................................83.1 Project Objectives..........................................................................................................83.2 Stakeholder Analysis...................................................................................................10

3.2.1 Internal Stakeholders...........................................................................................103.2.2 External Stakeholders..........................................................................................11

3.3 Stakeholder Quality Requirements..............................................................................133.4 Scope...........................................................................................................................15

3.4.1 Scope Inclusions..................................................................................................153.4.2 Scope Exclusions.................................................................................................16

3.5 Constraints...................................................................................................................174 Project Assumptions.............................................................................................................18

4.1 Related Projects...........................................................................................................204.2 Expected Timeframe....................................................................................................20

5 Acceptance Criteria..............................................................................................................21






document.doc

1 Introduction

PurposeThis section provides a brief summary of why this document exists and who should use it. This includes the document purpose, intended audience and document references.

1.1 Purpose

PurposeThis section should concisely describe key reasons for the existence of this document focusing on what it must communicate to the intended document audience.

Content ExampleThe Project Brief defines a project to meet the Business Case business objectives and business solution. It provides a high-level description of what the project will do in support of the Business Case. It includes:

o The Project Objectives required to meet the Business Objectiveso Business Case Summaryo Project Scopeo Project Outcomes and Productso Project Quality and Acceptance Criteriao Known Risks

1.2 Audience

PurposeList the key intended audience types for this document.

Content ExampleThe intended audience for this Project Brief is as follows:

Project Sponsor, Project Board, Project Architect Project Development Manager

1.3 References

PurposeList any documents referenced by this document.

Usage GuidelinesThe list of references should include:

Any documents used in the creation of this document. Any documents that provide supporting information to this document, including Work

Products produced by the project or external documentation.






document.doc

Content Template

Ref. Product ID & Name File Name / Location Version

1. [Id] [Name] [Description] [Vers]

Content ExampleThe following products are referenced by or were used in creating this document:

Ref. Product ID & Name File Name / Location Version

1. PD087 Business Case for Project Magellan Executive Document Drive 1.0

2. PD099 Project Magellan Acceptance Criteria Project Drive 1.1

2 Project Mandate

PurposeThis section describes what authority initiated the project and who has been appointed to manage the project.

2.1 Project Sponsor

PurposeDefine who is ultimately responsible for authorisation of the project.

Usage Guidelines Clearly identify who is the Project Sponsor. This is usually a senior manager of the

business area that stands to benefit most from the project. The Project Sponsor is someone who has the ultimate authority over the project. He or she

authorises the project budget.

Content ExampleThe project sponsor for this project is the General Manager of Sales and Marketing; Vito Castaneda.

2.2 Project Management Appointment

PurposeDescribes the project management structure for the project and who has been appointed in the project management role(s).

Usage Guidelines Describe the project management structure, roles and responsibilities. At a minimum list who has been appointed as the Project Manager and whether any other

Project Management/Executive roles have been appointed.

Content ExampleJolene Devreis has been appointed project manager for this project.






document.doc

She will report to Tulley McIver (Project Director) who will chair the Project Board and represent the business sponsor on day to day project matters.

2.3 Background

PurposeProvide a short summary of the Project, providing sufficient information to enable any reader unfamiliar with the project to understand the reasons behind the project along with any activities undertaken in preparation and any previous attempts at overcoming the problems and why they were not successful.

Usage Guidelines The Project Background should be no greater than 1 page. Where the author feels that

additional detail is required, this should be achieved by reference to existing documentation. The Project Brief will have wider audience than the Business Case so it may be appropriate

to duplicate the content from the background and problem or opportunity sections of the Business Case for this section.

Content ExampleMaxi Music has recently become the county’s largest retailer of musical instruments and music accessories. It is made up of the following lines of business:

Musical instrument and accessory sales.

Instrument service and repair.

Music studio equipment sales (specialising in the small commercial and home studio markets).

Musical instrument and studio equipment hire.

Music training (instruments, studio production techniques, music composition).

This position has come about as a result of business acquisitions over the last 12 months. The company now has 32 retail outlets nationally including 12 Super-Stores with on-site training facilities and one service and repair centre per capital city.The company is now entering a period of operational consolidation and revenue growth though increased market share with the aims of:

1. Opening no new retail outlets for at least 6 months.

2. Initiating an aggressive brand marketing campaign.

3. Leveraging new sales channels (specifically online).

After recent retail outlet acquisitions and operational rationalisations, Maxi Music has the operational infrastructure to pursue its market share growth, revenue and profit targets.The key challenges the company now faces are:

The market drift to online sales; especially for music accessories and studio equipment, but to a lesser degree for musical instruments.

Communicating the company brand and services to the market. This includes both existing customers but also potential customers in regions where the Maxi Music brand is relatively unknown.

Brand marketing and advertising is covered by another project run by the Sales and Marketing division. The Magellan project will tackle the need to establish and online sales capability.Currently Maxi Music’s online presence is lagging behind our competitors and does not to offer online sales. The current web site only includes:

Store locations

Product catalogue

Service descriptions






document.doc

Training course schedules

Contact information

Customer feedback form

Importantly, it does not cover: Online sales ordering and payments

An indication of which products are available at which stores

Training course, repairs or equipment hire bookings

2.4 Business Case Summary

PurposeThis section is intended to provide a summary of the rationale for undertaking the project.

Usage GuidelinesIf a separate Business Case document exists whose contents can be viewed by all project staff, then there is no need to restate this here, simply refer to it as an external document reference. For larger (or complex) projects, development of the Business Case may represent a

significant activity in its own right and should be captured as a separate document for which a template is provided.

If a separate Business Case document exists whose contents can be viewed by all project staff, then there is no need to restate this here, simply refer to it as an external document reference.

If a separate Business Case document exists but it contains business confidential content that is not appropriate for general project staff viewing, then those aspects of the Business Case that are not confidential should be restated or copied into this section.

Where a Separate Business Case document will not be created, this section should contain these details here. Use the Business Case template provided for content structure summary and guidelines.

Content ExampleKey information from the Project Magellan Business Case (not already covered in the project background above) is listed below.Competitive Drivers:

Maxi Music needs to enter the online musical equipment market to combat the growing loss of market share to web-based sales and auction sites such as eShopper.com.

Maxi Music needs to lead thee local retail market in service innovation.Online Channel for sales promotions:

Maxi Music should leverage its entry into the selling via online channel by initiating sales campaigns and promotions online.

Leverage outcomes from other business initiatives: The national inventory integration project already in progress is an enabler to for online

sales and product availability enquiries. Future productivity gains and IT responsiveness to business initiatives can be leveraged

from the “IT Tomorrow” initiative to expand Maxi Music IT applications capabilities.

2.5 Expected Outcomes

PurposeProvide a summary of the required outcomes of the project. This section should provide a short summary of the major items that will be delivered by the project, not so much in terms of the






document.doc

specific configuration items to be delivered but in terms of the improvements in capability that that the project is to deliver.

Usage Guidelines This information is provided in detail in the Business Case so should this section should only

contain the key or high-level outcomes. The Expected Outcomes should be no greater than half a page.

Content ExampleProject Magellan is will deliver the following business outcomes:

Grow product sales through the delivery a new Online Sales System (OSS) that allows customers anywhere in the world to purchase and pay for any Maxi Music product via the internet.

Improve customer service through the Delivery a new Online Service Centre (OSC). Grow service (Repairs, Training and Hire) sales through the Delivery a new Online

Service Centre (OSC). Increase staff productivity through the Delivery a new Online Service Centre (OSC).

3 Project Description

PurposeDescribe the Project providing an unfamiliar reader with the necessary information to clearly understand the project objectives and project boundaries.

3.1 Project Objectives

PurposeList the project objectives that must be achieved in order to meet the business objectives from the Business Case.

Usage Guidelines Map each project objective to the business objective(s) it helps achieve. The project objectives should describe what the project will need to do at the high level. The project objectives should be aligned, using similar terminology, to the Business Case. Project objectives should be measurable and unambiguous. Optionally provide a further description of the objective to clarify any ambiguity.

Content Template [Business Objective Id] - [Business Objective]

[Id] [Project Objective Title]

[Project Objective Description]

Content ExampleBO1 - Achieve 10% of product sales revenue from the online within 12 months.

1-1 Online Sales System (OSS) – Sales Order Subsystem

Build and deploy a system to allow customers to browse, order, pay for and arrange delivery of Maxi Music products via an online Web interface as part of maximusic.com






document.doc

1-2 OSS Sales Order Management Reporting

Build and deploy a system to provide management with online sales analysis and reporting

1-3 System Integration

The OSS integrates with the existing core business systems (e.g. Inventory, Accounting and Shipping).

1-4 Customer Service Helpdesk

Establish a customer service helpdesk to service customer problems queries (mostly from online customers) via email and phone.

BO2 - Achieve 20% growth in sales overall within 12 months without additional stores or core business staff.

2-1 Online Sales System (OSS) – Sales Campaign Subsystem

Build and deploy a system to support online sales promotions, campaigns, loyalty schemes and special offers

2-2 OSS Sales Campaign Management Reporting

Build and deploy a system to provide management with sales promotions, campaigns, loyalty schemes analysis and reporting

BO3 - Reduce the staff overhead of managing Course, Hire and Repairs bookings by 60% in 6 months.

3-1 Booking and Schedule Management Process Rationalisation

Streamline and rationalise the current booking and schedule management processes across the Hire, Training and Repairs business areas

3-2 Online Service Centre (OSC)

Build and deploy a system that supports the streamlined booking and schedule management processes

3-3 Manage Staff Redeployments

Ensure staff impacted by roles changes are support though this transition.

3.2 Stakeholder Analysis

PurposeList all parties impacted by the project including specific teams/groups/individuals from both internal, customer and external organisations that need to be consulted during project planning.

3.2.1 Internal Stakeholders

PurposeList the specific stakeholder teams/groups/individuals internal to the organisation and the products they require of and/or must provide to the project.

Usage Guidelines Optionally a project context diagram to represent the internal stakeholder dependencies.






document.doc

Internal stakeholders may include: change management, HR, IT Operations, IT services, business experts and representatives, auditors, governance bodies, standards teams.

Content Template

Stakeholder Name and Stake Description Primary Contact

[Name]

[Stake Description]

[Contact details]

Content Example

Stakeholder Name / Stake Description Primary Contact

Human Resources (HR)

Manage changes to staff job roles, staff communications and staff redeployments.

Melissa Chan

[email protected]

Sales and Marketing

Primary provider of business requirements for the OSS solution

Will be required to restructure to support the new sales channel

Tania Polkov

[email protected]

Instrument and Equipment Hire

Provide requirements for the OSC solution.

Manage operational rationalisation.

Pablo Sylvian

[email protected]

Repairs and Service


Manage operational rationalisation.

Günter Friedl

[email protected]

Training and Education


Maria Anderson

[email protected]

Purchasing, Stock and Distribution

Manage product delivery for online sales orders.

Provide stock details or online sales orders and enquiries.

Peter Stockhausen

[email protected]

IT Applications and Infrastructure

Responsible for managing all IT aspects of the project.

Will need to grow in response to the needs of this project.

Alex Pateras

[email protected]

3.2.2 External Stakeholders

PurposeList the specific stakeholder teams/groups/individuals external to the organisation and the products they require of and/or must provide to the project.






document.doc

Usage Guidelines Optionally an organisation/project context diagram to represent the external stakeholder

dependencies. External stakeholders may include: Customers groups, IT service providers, hardware

suppliers, unions, external auditors or regulatory bodies.

Content Template

Stakeholder Name and Stake Description Primary Contact

[Name]

[Stake Description]

[Contact details]

Content ExampleThe following external stakeholders will need to be managed as part of this project.

Stakeholder Name / Stake Description Primary Contact

Customers

Existing customers will be the subject of a new service awareness marketing campaign

The general public will also be the subject of a Maxi Music promotion campaign

Trish Takata

[email protected]

(Campaign Planning - Sales and Marketing)

Product Suppliers

Will need to fulfil more orders from Maxi Music under the just-in-time stock terms

New suppliers will need to be found for some product lines

Ted Newman

[email protected]

(Buying Manager – Purchasing Inventory & Distribution)

Corporate Auditors

Will conduct financial audit of the sales process and system.

Sebastian Westlake

(Principal Auditor – Potter-Westlake Auditors)

[email protected]

Internet Payment Service Providers

Will provide secure online payment services.

To be determined.

Shipping & Postal Service Providers

Will need to negotiate agreements for high volume postal and courier delivery from online sales

Heather Beckett

[email protected]

(Distribution Manager – Purchasing Inventory & Distribution)

ISP & Web Hosting Provider

Will need to provide increased Internet and Web hosting capacity and service levels.

Rachel Peel

[email protected]

(Account Manager – Switched-On Hosting)

The following diagram shows the external stakeholders impacted by this project.






document.doc

Postal Services

Product Suppliers

Shipping

$

Secure Internet PaymentService Provider

Globe MusicPty Ltd

Customers

Auditors

ISP & Web Hosting

Provider

3.3 Stakeholder Quality Requirements

PurposeList the project sponsor and key stakeholder quality requirements that will be used to drive the project and quality planning activities.

Usage Guidelines Provide a definition of the known quality requirements or expectation for each stakeholder. These will be used as input to product-based planning and solution requirements activities.

Content TemplateStakeholder Quality Requirements

INTERAL

[Name] [Description]

EXTERNAL

[Name] [Description]

Content ExampleThe following stakeholders have provided the following solution quality requirements. These requirements will be elaborated upon during product-based planning and the solution definition stage. Stakeholder Quality Requirements

INTERNAL






document.doc

Human Resources All staff redeployments and role changes comply with industry and government regulations.

Maxi Music HR policies are adhered to.

Sales and Marketing The full customer sale process can be supported by the OSS (i.e. order placement to payment and shipping request) with only minimal manual intervention from staff.

Customer privacy regulations are adhered to.

All sales data is securely stored and managed.

At least all products available from stores must be made available online.

Instrument and Equipment Hire

At least all of the current system functionality is supported by the new solution.

Service and Repairs At least all of the current system functionality is supported by the new solution.

Training and Education

The new solution does not causse any disruptions to existing course bookings.

Purchasing, Stock and Distribution

The OSS will only allow products that are either in stock or available from a supplier on just-in-time terms to be sold online.

Products out of stock without a confirmed price or delivery date may have a pre-order enquiry.

All shipped items must have insurance.

IT Application and Infrastructure

The business must conduct solution User Acceptance Testing.

Domain specialist business representatives must be made available to work within the project team.

EXTERNAL

Customers All financial transitions must be 100% accurate.

Secure Internet payments transitions must be available.

Customer data must remain confidential.

Product Suppliers None provided.

Auditors All financial transitions must be conducted to government and industry regulations and be open and traceable.

Internet Payment Service Provider

The solution adheres to the usage policy and guidelines of the service provider.

Shipping & Postal Service Providers

Clear and accurate delivery address information must be provided.

A shipment volume projection should be provided for service planning.

ISP & Web Hosting Provider

Future capacity and growth requirements should be provided for infrastructure planning and provisioning.






document.doc

3.4 Scope

PurposeProvide a clear indication of broad items, areas and high-level products that are within or outside of the scope of the project. Particular attention should be given to any items that are likely to be contentious or the subject of discussion between stakeholders and the project management team.This high-level description of the project scope is a key input to project planning.

Usage Guidelines The project objectives and stakeholder analysis are used as input to defining the project

scope. Ensure there is clarity in areas of responsibility between the project and its external interface

teams. For example, does the project scope include or exclude replacement or creation of any interfaces which may be supported by existing systems?

Clarify items that may be seen as responsibilities of other teams or projects in an organisation such as existing data cleansing or migration, training, computer hardware setup and installation etc.

The Project Scope should be no greater than 3/4 of a page. Where the author feels that additional detail is required, this should be achieved by reference to external documentation.

3.4.1 Scope Inclusions

PurposeProvide a list of high-level items that are within scope of the project to provide the audience with a list of things the project will provide and as an input to initial project planning.

Usage Guidelines Group or categorise items of scope to make is easier for the reader understand. Categories

may include:o Business Process Scopeo System Interfaceso Business Change Scope

Content TemplateId Scope Item Name & Description

[Category]

[Id] [Name] - [Description]

Content ExampleThe following items, features or products are included in the scope of this project.Id Scope Item Name & Description

Business Processes in Scope

1. Online Sales: Product/Sales/Shipping Enquiry, Quote Order, Raise Order, Order Payment, Fulfil Order, Order Shipping, Invoicing, Returns.

2. Booking and Schedule Management: Equipment Hire, Training Course, Instrument Service & Repairs






document.doc

3. Online Sales Promotion

New or Changed IT Systems in Scope

4. New Online Sales System (OSS) to support/automate the Online Sales process.

5. New Online Service Centre (OSC) to support/automate the Booking and Schedule Management & Online Sales Promotion processes.

6. Replace the current Booking and Schedule Management systems: Hire Management System (HMS), Training Booking & Schedule (EXCEL workbooks) and Instrument Service System (ISS).

7. Replace the product catalogue and customer service pages on the current Plant Music web site (Maximusic.com).

IT System Interfaces in Scope

8. National Inventory System. Provide all product inventory information and receive inventory updates for OSS.

9. Product Database. Product and pricing details for OSS.

10. Customer Database. Customer details for OSS and OSC.

11. Accounts. Financial transaction details from OSS and OSC.

12. Shipping. Shipping status enquiring information and shipping requests OSS and OSC.

13. Management Reporting System. OSS and OSC to provide business data for reporting.

Business Change Activities in Scope

14. User training and education for all users impacted by new or changed systems and processes.

15. Establishment of a customer service helpdesk to support online users.

3.4.2 Scope Exclusions

PurposeProvide a list of things that are not included in the project scope and why to help clarify any potential ambiguities.

Usage Guidelines Exclusions are commonly dependent products or activities that may the responsibility of a

team outside of the project or are provided are provided by shared corporate services groups. For example:

o UAT test datao Server software licenseso Updated business process and job role definitions

Content TemplateExclusion Name & Description Exclusion Reason

[Name] - [Description] [Reason]






document.doc

Content ExampleThe following items are not included in the scope of this project.Exclusion Name & Description Exclusion Reason

New Service Advertising and Promotion Covered by the “One Maxi” project.

Nation inventory system integration. Covered by the Nation Inventory initiative.

Establishment of new IT department capability. This is covered by the “IT Tomorrow” project.

Job role and work instruction changes. Covered by a HR project.

3.5 Constraints

PurposeList any constraints under which the project must operate.

Usage Guidelines Constraints may be time-based, financial, and personnel-based. Group constraints into categories, for example: Timeframe, Financial, Personnel.

Content Template

Id Constraint Description

[Category]

[Id] [Description]

Content ExampleThe project must operate under the following known constraints.

Id Constraint Description

Timeframe

C01 The development, integration system stage of the project can not commence prior to May due to budget allocation constraints.

C02 The Solution Definition stage must be complete by end May. Due to financial year end, sales staff will have limited availability to participate in the project.

C03 OSC must be live by June to meet business plan targets.

C04 OSS must be live by September to meet company revenue targets.

Financial

C05 Capital expenditure requirements cannot exceed a budgeted $900k in the current financial year.

C06 Total project budget to production cannot exceed $2.8M.

C07 A budget of $300k must not be exceeded for the first year of IT support for new/changed systems.

Personnel






document.doc

C08 Due to existing commitments, participation from Accounting team representatives within the definition stage of the project cannot exceed 1 FTE from the existing team for the duration of the definition stage.

C09 All key project IT roles must be filled by Maxi Music staff in support of knowledge retention.

C10 Existing IT department staff skills and knowledge should be leveraged where possible.

Technical

C11 The OSS and OSC will be custom developed solutions which may be use third-party software components only where approved by the Architecture Governance Committee.

C12 Existing Core System databases and systems must be used (see interfaces in scope listed in this document).

4 Project Assumptions

PurposeList any assumptions made to communicate how unclear requirements or constraints have been interpreted when defining this plan.

Usage Guidelines Assumptions are way of verifying understanding of scope or impacts of constraints upon

delivery. Some assumptions may stimulate discussions with reviewing stakeholders and potential

changes to plan scope. Group assumptions into categories, for example:

o Organisationalo Scopeo Technicalo Financialo Resourceso Timeframeo External Dependencies

Content Template

ID Assumption

[Category]

[Id] [Assumption]

Content ExampleThe following assumptions have been made in defining this project.

ID Assumption

Organisational






document.doc

A01 The Repairs, Training and Hire booking and schedule processes can be rationalised into one that supports the needs of each business unit.

A02 No additional core business staff (apart from any required for the new helpdesk) will be required directly as a result of this project.

Resources

A03 The project team includes staff from the impacted business units that are empowered to make critical decisions regarding business process and requirements.

A04 The IT Applications and Infrastructure department can fulfil the project IT staff requirements in the timeframes required.

Scope

A05 OSS and OSC reporting requirements can be met by using the existing management reporting system.

Cost

A06 An overall blended rate of no more than $800 per day is expected to be paid for vendor or contractor consulting services.

A07 Although new IT technical infrastructure has been included in cost estimates, these estimates assume the existing infrastructure can also be used.

Technical

A08 The OSS and OSC systems will be implemented using a best practice technical platform that has a large existing skills-base in the market. An unreasonable premium is not expected to have to be paid for any external IT services required.

A09 The solution architecture will be consistent with the Maxi Music Enterprise Architecture Blueprint.

4.1 Related Projects

PurposeList any Related Projects which may impact the project delivering to its objectives or need to be considered during project planning.

Usage Guidelines Include the high-level products required form or to be delivered to the project.

Content Template

Id Project Name Products Required By Products Required From

[Id] [Name] [Product] [Product]

Content ExampleThe following projects are impacted by this project. They have to either provide products to or require products from this project.

Id Project Name Products Required By Products Required






document.doc

From

P0172 National inventory system integration

OSS Interface requirements

Single interface for Inventory data

02/119 “One Maxi” marketing project OSS and OSC capabilities

System requirements

Promotion Content

P0189 “IT Tomorrow” project Skilled IT systems development staff and infrastructure

4.2 Expected Timeframe

PurposeIndicated what he expected time frame for solution delivery is. Include any milestones required during delivery.

Usage Guidelines What is the expected timeframe for delivery of the project? Are there any timeframe

constraints that should have been included within the constraints section? Where the major stages of the project are known in advance, the author may wish to

consider the likely timeframes for major project milestones. A table of high-level activities with start and end dates or a high-level Gantt chart may be

used to communicate the expected time frame. This section should include a short analysis of:

o Required Project time frames.o Likely time frame for implementation in consideration of expected project approval

procedures used within the organization. o Required delivery dates to the products required to be delivered.

Content Template

Stage / Activity Planned Start Planned Finish

[Stage]

[Activity] [Date] [Date]

Content ExampleThe following Gantt chart shows the target project time frames which will be verified during project planning and solution definition activities.






document.doc

Task Name Duration Start Finish

Project Launch Pad 33.6 wks 2 Feb 25 Sep

Project Establishment 4 wks 2 Feb 1 Mar

Project & IT Infratsructure Establishment 4 wks 2 Feb 1 Mar

Solution Definition 10.4 wks 12 Feb 24 Apr

Business Process Definition 6 wks 12 Feb 23 Mar

OSC System Architecture & Requirements 5 wks 26 Feb 30 Mar

OSS System Architecture & Requirements 7 wks 7 Mar 24 Apr

Solution Development, Integration & Test 21.2 wks 20 Mar 14 Aug

OSC Development, Integration & System Test 9 wks 20 Mar 21 May

OSS Development, Integration & System Test 18 wks 11 Apr 14 Aug

Solution Acceptance 17.2 wks 22 May 18 Sep

OSC User Acceptance Test Execution 3 wks 22 May 11 Jun

OSC System Acceptance 1 wk 12 Jun 18 Jun

OSS User Acceptance Test Execution 4 wks 15 Aug 11 Sep

OSS System Acceptance 1 wk 12 Sep 18 Sep

Solution Deployment & Review 15.2 wks 12 Jun 25 Sep

OSC IT Deployment 1 wk 19 Jun 25 Jun

OSC Business Deployment 2 wks 12 Jun 25 Jun

OSS IT Deployment 1 wk 19 Sep 25 Sep

OSS Business Deployment 4 wks 29 Aug 25 Sep

2 Feb 1 Mar

12 Feb 23 Mar

26 Feb 30 Mar

7 Mar 24 Apr

20 Mar 21 May

11 Apr 14 Aug

22 May 11 Jun

12 Jun 18 Jun

15 Aug 11 Sep

12 Sep 18 Sep

19 Jun 25 Jun

12 Jun 25 Jun

19 Sep 25 Sep

29 Aug 25 Sep

Jan Feb Mar Apr May Jun Jul Aug Sep Oct

5 Acceptance Criteria

PurposeSummarise the project acceptance criteria that are or will be fully defined in the Acceptance Criteria document.

Usage Guidelines It is appropriate to include point level acceptance criteria in this section as part of an initial

draft document only. The Quality Criteria document is referenced here once it is created.

Content ExampleThe acceptance criteria for this project are listed in the Project Magellan Acceptance Criteria [2] document.






Project Brief

Documents

progo template library

document version

document status

sample template

project mandate

project sponsor

project description

project objectives