TEMPLATES BUSINESS REQUIREMENTS AND USER STORIES

POSSIBLE HEADING FOR BUSINESS REQUIREMENTS

Requirements Overview
Include this section in a detailed requirements document to provide a high-level summary of what is trying to be achieved.

Scope
Definition of the areas that have been included the analysis and those that have been specifically excluded.
This may include organisational areas, processes, customer types/segments, systems, business locations.
Where out-of-scope items may be contentious, state reasons for exclusion.

Requirements Definition
Details of the functional requirements to be delivered.
You may be using a process-driven approach or a tabular listing of requirements. Whichever approach, it should be clearly stated whether each requirement is mandatory, optional or nice-to-have. Or, use whatever classifications have been agreed within your project
If using a process driven approach then non-functional requirements (below) may need to be related to each process. Otherwise sections 8 to 11 will be required to state the non-functional requirements.
Sections 8 11 may not be required for a high-level requirements document and some may not be required where there are no systems components to the project.

Process maps
Add or link to process maps here

Constraints
Include details of any imposed constraints on the requirements. For example, where it is known that integration into an existing system cannot be achieved or there are externally imposed time constraints. State reasons for constraints such as legal or regulatory.

Location/User Groups
Details of the user groups affected by the change or who will be using new functionality. Include details of known locations for each user group and the number of users in each location.

Security Requirements
Details of any security requirements such as supervisory access, or how access should be prevented to non-authorised users. Do not include requirements which are already defined generically for the organisation in question.

Service Level Requirements
Details of the required availability of a proposed system (e.g. 24 hours, 365 days per year) and the level of resilience required (e.g. maximum downtime = 1 hour per month). Include details of required response times but only where there is a specific need not covered by the organisations generic rules.

Volumes
Include details of average and peak volumes across all processes/transactions and any anticipated growth in these volumes. State clearly when any peaks occur.

Dependencies
Details of any external event, task or project which has a material influence on delivery of these requirements.
The following further sections may be required depending on the nature of the project and the level of requirements being defined. You may choose to include them as appendices or within the main body of the document.

Data Model
Likely to include an Entity Relationship Diagram and entity descriptions

Data Conversion Requirements
Required where data is to be converted/migrated from an existing set of processes whether manual or automated.

SIMPLE FORMAT FOR REQUIREMENTS

Ref	Description	Who Raised	MSCW	Accept or Reject	Success Criteria
Item Name /Title	Item Description	Owner/Customer	Must Have, Should Have, Could Have	YES or NO	Detail of specification / criteria
Item Name /Title	Item Description	Owner/Customer	Must Have, Should Have, Could Have	YES or NO	Detail of specification / criteria
Item Name /Title	Item Description	Owner/Customer	Must Have, Should Have, Could Have	YES or NO	Detail of specification / criteria
Item Name /Title	Item Description	Owner/Customer	Must Have, Should Have, Could Have	YES or NO	Detail of specification / criteria

COMPLEX FORMAT FOR REQUIREMENTS

Functional Requirements

IP Outsourcing Key Requirements

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

User Interface

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Alerts and Warnings

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Maintenance Interface

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Customisation

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Reporting

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Security and Control

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Interface

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Non Functional Requirements

Availability

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Performance

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Security

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Data Storage, Backups and Recovery

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Supportability

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Scalability

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

Legal

Ref	Description	Who Raised	M S C W	Accept or Reject	Success Criteria

TYPICAL FORMAT FOR USER STORIES

Note in Agile we dont know exactly how long things take so instead of dates and a schedule we use Points to estimate effort

01 Quick to deliver and minimal complexity. An hour
02 Quick to deliver and some complexity. Multiple hours
03 Moderate time to deliver, moderate complexity, possible unknowns
05 Longer time to deliver, high complexity, likely unknowns
08 Long time to deliver, high complexity, critical unknowns
13 Long time to delivery, high complexity, many critical unknowns
21 Youre doing this wrong.

As a	I want	So that	Best product	Best Approach	Effort
Role/Person/Function	The function /ability or feature	The outcome / benefit / utility	What the 'thing' would be	How this might be done	Pts 3-5
Role/Person/Function	The function /ability or feature	The outcome / benefit / utility	What the 'thing' would be	How this might be done	Pts 3-6
Role/Person/Function	The function /ability or feature	The outcome / benefit / utility	What the 'thing' would be	How this might be done	Pts 3-7
Role/Person/Function	The function /ability or feature	The outcome / benefit / utility	What the 'thing' would be	How this might be done	Pts 3-8
Role/Person/Function	The function /ability or feature	The outcome / benefit / utility	What the 'thing' would be	How this might be done	Pts 3-9
Service Desk User	To understand the ROLE / RESP/ TASKS to be done on daily,weekly, monthly	Do my work and succeed against agreed SMART goals	Job Descrip.	One-to-One Meet	Pts 1-2

USEFUL REFERENCES

https://www.scalablepath.com/blog/agile-points-explained-fibonacci-sequence/

ATC TEMPLATE 06 HAND-OVER (TECHNOLOGY APPLICATION)

ATC TEMPLATE 06 HAND-OVER (TECHNOLOGY APPLICATION)

TECHNOLOGY PROJECT HANDOVER

COMMERCIAL/CONTRACTUAL

1. Requirements should be written into tender documentation/contracts in as much detail and as specifically as possible including engagement requirements, data environment and any standardisation of equipment or product that the client requires.

2. Whole life cost must be considered if at all possible. Does spending more now have an impact on the overall operating cost of the project throughout its life?

3. Incentivise success. If a scheme is well delivered, this should reward all parties.

PROCESS

4. Handover is a process not a date. Planning for it should be from the start of the project and it should be viewed as an incremental transfer of knowledge and operation from project team to business-as-usual.

5. The benefits and deliverables must be measurable and communicable from the start. Ask why are we doing this project and how will we know when it is done?

6. Involve end users from the outset. Through stakeholder analysis, understand who will benefit from the project, who will be required to facilitate the delivery of the benefits and how the project outputs will impact their role.

DATA AND KNOWLEDGE TRANSFER

7. Documentation must be written for the end users. It may require different sets of documentation for different users but for documentation to support knowledge transfer it needs to be meaningful, applicable and relevant to the end users.

8. Collate lessons learned as the project progresses. It provides more meaningful data for future projects, it can be tied to stage gateways or key deliverables.

9. Agree the information requirements at the outset. This ensures all parties have a clear deliverable, know what is expected of them and work towards achieving the goal from the start of project.

PEOPLE

10. Often overlooked but put simply get good people on your project and keep them for as long as you are able.

11. Definition of stakeholders should be carried out throughout and in detail. Who will be impacted by the project and who is needed to make it a success?

12. The client role is pivotal including client engagement.

TABLE / TEMPLATE

Checks	Documentation / Deliverables
SYSTEMS INFRASTRUCTURE & NETWORK DESIGN (WHAT IT LOOKS LIKE)
Have adequate system & architectural diagrams (under version control) been produced? Do they provides a basic description of the systems overall purpose as well as its primary functional components and their relationships?	Location of equipment Hardware configuration / specification Network configuration diagram Relevant logical and physical system diagrams and flowcharts Hostnames Database names Application names Interfaces Environments Dependencies upon / interdependencies with other systems and applications What support / maintenance agreements are in place
SOFTWARE OVERVIEW (WHAT'S INSTALLED ON IT)
Have details of all software elements (OS, Application, Middleware etc) been produced?	What software / application versions are installed What licenses have been purchased Where the licenses are kept / recorded What support / maintenance agreements are in place
SYSTEMS BUILD INSTALLATION (HOW TO INSTALL IT)
Has a detailed description of the installation process for the complete solution been produced?	Hosting requirements, installation & configuration including power, air conditioning, racking, secure access System installation procedures from bare metal including environment setup and configuration details Detailed Install Guides on how the applications is loaded including where the software is located / stored, and license installation procedures
VERIFY THE SYSTEM BUILD (TEST INSTALLED CORRECTLY)
Has the basic build been tested	Test end 2 end functional and System acceptance test plan and expected results
DISASTER RECOVERY & FAILOVER RESILIENCE (WHAT IF SCENARIO TESTING FOR DIFFERENT OUTCOMES)
Have all changes / amendments to the Disaster Recovery & Test plan been captured, including details on what is required to fail the system / application over to the contingent system in the event of a failure of the production service?	Identify the triggers for automatic failover What is the sequence of events during automatic failover How do you know the automatic failover has been successful or not How you recover back to the Live environment The level of disaster recovery required and the recovery procedures in the event of a disaster invocation Identify the triggers for manual failover What is the sequence of events during manual failover - partial and complete What is the sequence of events during manual failover How do you know the manual failover has been successful or not How you recover back to the Live environment - partial and complete The level of disaster recovery required and the recovery procedures in the event of a disaster invocation
VERIFY THE DR CAPABILITY (TEST FAILOVER & RECOVERY PLANS)
Check DR is working	Performance & Stress test plan and expected results (including break point thresholds) Perform Failover and Failback Recovery Testing
BACKUP AND RECOVERY
Have system backup details / procedures been produced?	What is to be backed up When it has to be backed up (what time, how often) How it is to be backed up Where it is to be backed up to How much data is likely to be backed up What media is to be used Retention period of data Has this been signed off by the business owners (where is supporting evidence)
Have recovery details / procedures been produced?	Full system recovery from bare metal Partial system recovery Full data recovery Selective data recovery Restoration requirements / dependencies Impact / inputs to other systems
ACCOUNT MAINTENANCE / USER SET-UP & MANAGEMENT INSTRUCTIONS
Have user set-up procedures been produced that supports the way in which the Service Desk creates and manages user-ids?	How to set up a user-id How to change a user-id How to delete a user-id How to reset passwords User notification
BATCH PROCESSING INSTRUCTIONS
Has a description of each individual process been provided?	Description of what the process does Source and target system interfaces are explained Details on data being manipulated
Have Operation, Frequency, and Processing Time details been provided for all of the processes?	How the process is started (manual or scheduled)? Operational activity required during the running of the process What inputs are required What outputs are required / produced How often the process runs How long the process should run for What the volume of data is processed
Have the process Success / Failure indicators been defined?	How you can tell if the process has completed successfully or not How you can tell if the process is looping What output is produced All status exception messages are explained What the impact of failure is What action should be taken in the event of failure
If the process were to be interrupted prior to successful completion, what instructions must be followed to restart the process?	Restart procedures
How can the process be safely interrupted, if it becomes necessary to do so?	Interruption procedures
Have full details been provided for the Scheduling and Recovery of the batch process?	Predecessor Requirements Successor Requirements Interface requirements Scheduling Recovery Details Callout Instructions Disaster Recovery
PLANNED SYSTEM START UP / SHUT DOWN INSTRUCTIONS
Have instructions been provided to guide the operators during the startup and closedown process of a system or application, including emergency shut-down and startup procedures?	How to start / stop the system, application, or processes How to start / stop interfaces What messages are expected during start-up and closedown What sequence should be followed during start-up and closedown What responses are to be entered How to deal with unexpected responses Emergency start-up procedures
SYSTEM MONITORING & MAINTENANCE
Have the procedures to be followed for monitoring the computer system been produced?	The tools to be used for monitoring the systems and applications The indicators and interpretation of those indicators Components monitored purpose / function Threshold level settings Severity level settings details of impact Operator actions required Escalation Are there detailed error handling procedures Are there detailed notification & reporting procedures
Have System Maintenance requirements been documented?	What are the agreed maintenance schedules / slots Have the maintenance schedules been agreed with the business List the terms of external maintenance contracts with suppliers and engineers
Have detailed trouble shooting procedures and FAQ's been produced?	The error messages or other indicators accompanying those problems The automatic and manual procedures to be followed for each occurrence Evaluation / trouble-shooting techniques Conditions requiring application or system shutdown Procedures for on-line intervention and the steps to be taken in the event that on-line intervention requires a restart Any special requirements for recording information concerning a problem / failure should also be included
SERVICE AGREEMENTS
Has an SLA been documented and agreed with the Business?	Agreement in place between IS and the Business
Have Third Party arrangements been agreed and signed off and supporting agreements / documentation location idenfied?	Supplier 1 Supplier 2 Supplier 3 Supplier 4
OPERATIONAL SKILLS, RESOURCES AND TRAINING
Have resource or skills shortages been identified	Define roles and skills required
What training requirements have been identified	New Training for Existing staff Knolwedge transition required from project team members to operational staff Agree project team involvement in Operations during Warranty Ongoing Training Plan for knowledge sharing and personal development
SERVICE DEFINITION
Have Service Owners been identified and agreed?	Business Service owner IS Support owner(s) Third Party Support owner(s)
Has the Support Model been documented and agreed?	Support relationships 1st, 2nd, 3rd line responsibilities Support Matrix Support obligations Service Hours and Service Levels
Have full support contact details been provided (a copy of project Communication Plan is sufficient) ?	Name Position Company & Department Location Land line number Mobile phone numbers E-mail address Alternative contact Escalation procedure
GLOBAL SUPPORT PROCESSES
Has the Service Desk tool been configured in support of the Service and Reporting requirements?	Agreed and configured CTI's Resolver groups configured Resolution and cause codes configured Escalations and notifications configured Knowledge base populated Report templates produced Asset information captured in toolset as required Service Desk licenses procured and agents rolled out as necessary Training material produced
Have the Incident Management process and procedures been reviewed and amended in support of the Service requirements?	Reviewed / revised Incident Management process Process interfaces / dependencies 1st line support procedures Incident workflow Third Party Incident Management
Have the Problem Management process and procedures been reviewed and amended in support of the Service requirements?	Reviewed / revised Problem Management process Process interfaces / dependencies Known Errors Problem database Root Cause Analysis (RCA) template
Have the Configuration Management process and procedures been reviewed and amended in support of the Service requirements?	Reviewed / revised Configuration Management process Process interfaces / dependencies Populated CI database
Have the Change and Release Management process and procedures been reviewed and amended in support of the Service requirements?	Reviewed / revised Change and Release Management process Process interfaces / dependencies
Has the Anti Virus & Patch Management policy been defined and the process and procedures amended in support of the Service Requirements?	Policy / process in place Process interfaces / dependencies Procedures defined for Emergency, Critical, Standard, and Maintenance patches Deployment schedule defined Test schedule defined Responsibilities agreed
SECURITY MANAGEMENT
Has the security model been defined?	Infrastructure (hardware, network) OS Database Application User profiles / access How is security monitored / maintained
Has the security model been tested?	Internal testing Independant 3rd Party penetration / application testing Risks / vulnerabilities identified Mitigation / corrective actions agreed
WARRANTY
Is there a Warranty Statement agreement in place ?	Entry Criteria Exit Criteria Competencies Governance
Is the Warranty Support Model defined?	Organisation (People, inc Third Parties) Support processes Support tools Defect handling procedure Transition Plan
Are full support contact details provided?	Name Position Company & Department Location Land line number Mobile phone numbers E-mail address Alternative contact Escalation procedure

USEFUL REFERENCES

Agile documentation: Handover to production support
https://kingsinsight.com/2011/02/10/agile-documentation-handover-to-production-support/

ITIL-Checklists [Incident Management / Service Desk]
https://wiki.en.it-processmaps.com/index.php/ITIL-Checklists#ITIL_Service_Transition_Templates

ITIL Service Operation Roles:
https://www.certguidance.com/processes-wise-itil-roles-itsm/#sorole

12 factors for the successful handover of projects
https://www.apm.org.uk/resources/find-a-resource/project-handover/12-factors-for-the-successful-handover-of-projects/

Code Documentation: How To Create Effective Handover Documentation
https://praxent.com/blog/software-handover-documentation-checklist

SCRUM - ROLES AND RESPONSIBILITIES

Agile, Scrum, Waterfall, Kanban are different project management frameworks which are helping the companies to increase the productivity. These frameworks were created by the IT companies and especially web and application development companies because they needed a path but on which each and every employee can perform his daily tasks. However, out of these four frameworks, the Scrum is the most widely used framework in all the companies despite their nature of work. That is why in this article we are going to discuss the Scrum in detail to give you a better idea about this iterative framework which is making easier for the companies to complete their project.

SCRUM OBJECTIVE:

The basic objective of the Scrum is to keep the entire team on the same page throughout the project. The scrum framework allows the cross-functional work of the team of 4 to 10 members to provide the regular details and information sharing liberty so they can produce the best result. Scrum is a more like philosophical than the technical. It is a framework that can only be used as the guidance and there is no constant in it. All the success of the Scrum depends on the interactions among the stakeholders as it does the process.

SCRUM ROLES AND RESPONSIBILITIES:

The techniques of Scrum has become very popular and now considered to be the most important thing to do before starting any project. That is why the demand of the scrum masters and other professions related to the scrum has also increased, and people now are searching about the term scrum more.

The scrum is a very specific and précised framework that is why it comprised on the following roles.
Scrum Master
Product Owner
Scrum Team
Stakeholders

Because the term Agile is often get associated with the project managers that is why many people believe that the Scrum Master is also a term for the project managers. However, the Scrum Master serves very different purposes than the project manager. The Scrum Master works as a facilitator rather than the authoritative person who is responsible for the project delivery. The Scrum Master is a coach, motivator and problem solver who can only assist the team by using all his experience of Scrum framework.

According to many Scrum Masters, applying Scrum within an organization is not the actual scrum process. You have to make the organization to accept your new role and then change its culture which is the most difficult thing to do in any company. The prominent role of every Scrum Master should be to enhance the power of the team by committing them to the sprint goals without any interference from the management. Let’s discuss the major roles of all the above points separately.

SCRUM MASTER:

The Scrum Master is considered to be the top-dog in every organization because companies usually hire them and don’t treat them as permanent employ that is why they are with no authority.

It is their duty to remove all the hindrance or obstruction in the way of achieving any goal.
It is also their role to enforce scrum ceremonies and processes.
They are the ones who commit to goals and deadlines on behalf of the team.

PRODUCT OWNER:

The product owner is responsible for conveying the vision of the stakeholders to the team.
They have the authority to alter the scope.

The Product Owners are responsible for the return on investment (ROI) that is why they occupy an authoritative position in the firm.

Because they convey the vision of the stakeholders that is why they are the voice of the stakeholders.
Not only with the team, but they also communicate with the stakeholders about progress and problems.

SCRUM TEAM:

The Scrum Team is responsible for all the activities that lead them towards their sprint goals.
They have to work with the Scrum Master to prioritize the items from the product backlog in the sprint planning.

Once committed, it is their responsibility to fulfil the commitment and deliver the agreed results on time with great quality.

The Scrum Master is not responsible for keeping his team organized that is they it is the duty of the Scrum Team to get self-organized.

They have to be agile in the office and have to attend every standup and other ceremonies.
They have to participate in all the meetings despite their nature and have to ensure that all the findings of the meetings are getting practically addressed in the project.

STAKEHOLDERS:

The Stakeholder has to keep a healthy relationship with the Product Owner in order to share every detail regarding his project.

The Stakeholder is responsible for conveying his wishes and concerns to the product owner or else the product owner would not be responsible for his project quality and time duration.

The Stakeholder has to provide regular input to queries from the Product Owner.

Prioritizing the work affectively with the Product Owner is another job that the Stakeholder has to do to ensure his project development.

Keep taking updates or keep giving updates regarding any change in the plans.

USEFUL REFERENCES

Agile Scrum Roles And Responsibilities
https://www.knowledgehut.com/blog/agile/agile-scrum-roles-responsibilities

ATC TEMPLATE FOR TENDERS OR PROPOSALS

SUGGESTED CONTENT FOR A LETTER

The [Organization Name] wants to [outline product or services that are required and for which a tender (fixed product at lowest price) or proposals (suggestions) are being sought ].

At Appendix 1 is a Briefing Paper which frames the context and offers some information about [Organization Name]

We require that the selected provider

Add a summary list of product or services required and the success criteria for each.

The attached document sets out key information about [Organization Name] and the framework and timetable for this request for proposals. We would be grateful of you follow this framework when making your response so that we can properly understand, evaluate and select the preferred provider.

Yours Faithfully

SUGGESTED CONTENT FOR A REQUEST FOR PROPOSALS

This document sets out key information about [Organisation Name] and the framework and timetable for this request for proposals. This document is not intended as a formal specification and the reader should refer to the covering letter for a summary of our tax policy and outsourced provider requirements.

We would be grateful of you follow this framework when making your response so that we can properly understand, evaluate and select the preferred provider.

ABOUT THE ORGANISATION

Add a summary information about the organization .

PROPOSAL REQUIREMENTS

Executive Summary

Your response must include an Executive Summary summarising the key features of your proposal. This should be no longer than one page.

Information Requested

Your proposal must contain all of the information summarised in the covering letter and detailed in the sections below. Responses are to be submitted in the Section order set out and referenced accordingly. Emphasis should be given to those aspects that you consider appropriate in meeting the stated requirements and the unique benefits that your organisation can provide.We value brevity and a strong preference to a short, succinct submission. If generic fact sheets or marketing material is included in your response, it should be included as an attachment. We feel it should be possible to respond to this request for proposals at around more than one page per section (ie between 8 and 12 pages)

Section 1 Product / Service

Add a detailed description of the product or services required and the success criteria for each and what information you require from the supplier or contractor in their reply.

Section 2 Product / Service

Add a detailed description of the product or services required and the success criteria for each and what information you require from the supplier or contractor in their reply.

Section 3 Product / Service

Add a detailed description of the product or services required and the success criteria for each and what information you require from the supplier or contractor in their reply.

Section 4 Product / Service

Add a detailed description of the product or services required and the success criteria for each and what information you require from the supplier or contractor in their reply.

Section 5 - Fixed Fee Costs

Please provide the cost of your proposals we have a very strong preference for a fixed fee rather than working on an hourly basis.

We realize that to establish a fixed fee proposal you will want to discuss a lot of details and past experience with us before submitting proposals. If you have any queries we can arrange a phone or conference with [name of contact]

In the case of variable costs please indicate the names of the people involved, their charge-rates and indicative costs based on your experience working with similar organisations.

Person	Credentials	Charge-Rate

The above is a model table and can be modified as necessary

Please state any assumptions you have made in providing your costs.

Section 6 - Approach / Deliverables / Outputs

Your proposal should include a statement describing your understanding of the overall project objectives and how you plan to manage this project to achieve these objectives. [250 words maximum]

Please provide details of your proposed approach (plan of action) and proposed deliverables (output reports, advice, guidance)

Proposed Approach

In your response please consider the following
How you would engage with CICS and get up-to-speed
How you would review current arrangements
How you would recommend and advice on future arrangements
You approach to Tax Advice and Returns

Proposed Deliverables

In your response please identify any key documents or other deliverables

Please provide an organisation chart depicting members of the project team (including our client, your team, and third parties), reporting lines and communication lines. [Insert organisation chart or reference a discrete document.] Indicate expected roles (with titles) to be played on this project along with a detailed description of responsibilities. Include a listing of deliverables each role is responsible for.

Role	Responsibilities	Deliverables

The above is a model table and can be modified as necessary

Section 7 - Company Information

We are seeking focused responses, rather than responses which include a significant amount of standard marketing material. If marketing material is included in your response, it should be included as an attachment.

Please include the following in your response. Please keep this short because to will be used only as context for the Board and Executive Management Team, as part of the submission and evaluation process.

Give a brief profile of your Company (or link to website).
Describe your core products and services.
Summarise your service commitment to customers.
Describe your experience and qualifications relevant to the requested work.
Make special note of the assumptions that were made during the preparation of this response.
Indicate any relevant alliances, partnerships, or affiliations with other third-party organisations.

Section 8 - Related Engagements

Please supply details of at least two (2) similar past engagements, occurring within three (3) years prior to the publishing of this RFP Provide information to demonstrate the relevance that the engagement has to the to the requested work.

Details should include, but not be limited to:
Client contact information
Industry/Vertical/Market
Application, software and hardware platform
Implementation/rollout strategy
Business benefits realised
Lessons learned

Please include contact details as we are required to check references directly.

PROPOSAL PROCESS

Timetable

We realise that to establish a fixed fee proposal you will want to discuss a lot of details and past experience with us before submitting proposals. If you have any queries we can arrange a phone or conference with [name of contact]

You are required to:
Promptly acknowledge receipt of this RFP by email by [date]
Submit your response documents by email by [date]

Submission

You must deliver your Response in an electronic copy, in MS Office format. You must also deliver one (1) hard copy to the address shown below.

Email address: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Email subject: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hard copies to:

Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Confidentiality

It is a term of the receipt by you of this Request for Proposal that the subject matter and detail of this Request for Proposal is not disclosed by you to any third party without the prior written consent. All information provided in this document (and any information which may be subsequently provided to you orally or in writing in connection with this RFP) is proprietary and is highly confidential. At our request, please return all such information to us (together with all copies) on whatever media it has been supplied to you and/or certify to us that all such information (and copies) have been destroyed or deleted from your systems. The foregoing provisions do not apply to any such information, which is or becomes generally available to the public other than as a result of a breach of the foregoing provisions.

Costs Incurred

Each Party shall be responsible for its own costs in relation to the review and preparation of the response to this RFP, and for any responses made pursuant to it or any subsequent negotiations and contractual documentation. [organization name] shall in no way be responsible for any costs.

Withdrawal of Responses

The Supplier shall notify us immediately if, for any reason, they decide to withdraw from the process.

Rights to Use Third Parties

If the Supplier intends to use subsequently or has used subcontractors or consultants to prepare its Response, this should be noted in your Response.

Reasons

We reserve the right to make an award based solely on the information provided, to conduct discussion or request proposal revisions, if deemed necessary.

The Supplier(s) selected for further consideration will be chosen on the basis of our clients evaluation and determination of which Supplier will provide the greatest benefit to their organisation, not necessarily on the basis of lowest price. We have no obligation to reveal how Supplier proposals were assessed.

We retain the right to not award any Supplier upon completion of the RFP process.

End Of Document

ATC TEMPLATE 07 BENEFITS REVIEW

ATC TEMPLATE 07 BENEFITS REVIEW

Question to answer: Did we achieve our aims?
(On-time, on-budget, to-specification, with low-risk & high-communication?)

At this step we need to review of outcomes compared to the business case and plan. Key question are we trying to answer: Did we achieve our aims, on-time, on-budget, to-specification, with low-risk and high-communication?

The best approach is to revisit all the above steps to look at what happened, learn any lessons and measure success against your original goals in the Business Case or Plan. By recording this and sharing it the business is able to learn and improve.

DID WE ACHIEVE THE AIMS SET OUT IN THE BUSINESS CASE?

HOW DID WE DO AGAINST THE PLANNED SCHEDULE AND COSTS?

DID WE STAY WITHIN OUR ORIGINAL SCOPE OR DID IT CREEP?

DID WE ACHIEVE OUR GOALS WITHIN THE BUDGET?

WAS THE SUPPLIER HAPPY? HOW DID THE DESIGN & DEVELOPMENT OF THE PRODUCT GO?

WAS THE CUSTOMER HAPPY? HOW DID THE HANDOVER GO?

DID WE ACHIEVE OUR STRATEGIC GOALS?

WHAT CAN WE LEARN FOR NEXT TIME?

(You May Want To Use The Attached Journey Template To Map Out The Lessons Learned)

IS THERE ANYTHING STILL LEFT TO DO?

Open Action	Action Owner

AUTHORITY TO CLOSE THE PROJECT

Signed By:	Role / Department:	Date:
	Sponsor
	Finance
	SPCO

ATC TEMPLATE 06 HAND-OVER

ATC TEMPLATE 06 HAND-OVER

Question to answer: Is everything complete & ok?
(Can we hand over to business as usual?)

At this step we need to ensure there is a formal acceptance and hand-over to the operational teams running business as usual. Make sure you know what needs to be handed-over before you start, and make sure they have everything and agree it all before you finish/close. It is advisable to document the handover.

If you need any help planning your handover please contact the Strategy, Projects and Change Office

PLANNING THE HAND-OVER

WHAT SUPPORT ARRANGEMENTS ARE IN PLACE?

(Give a summary of the support arrangements that will be in place for the operational / business as usual teams.)

Date that the support arrangements will start
Service Availability & Hours of Support
Service Level Agreement(s)
Service Support Cost (annual)

Supplier(s)/ Contractor(s) Contact Details

Name	Email	Telephone

Customer Contact Details

Name	Email	Telephone

WHICH ROLES NEED TO BE TRANSFERRED?

(Give a summary of the tasks or job roles that will be transferred to the operational / business as usual teams.)

Team(s)	Current Task/Role Holder(s)	Task Definition Summary	Name & Team of Recipient

WHAT KNOWLEDGE OR INFORMATION NEEDS TO BE TRANSFERRED?

(Give a high-level summary of the knowledge or information that will need to be transferred to the business as usual teams. Provide detail of how and when this knowledge will be transferred, and where any documentation will be stored.)

Information that needs to be transferred	To which team / person?	How and when?	Where will any documents be stored?

COMMUNICATION & MANAGING EXPECTATIONS?

(Give a high-level summary of how the project team is communicating with the operational teams. Please include details of key meetings and communications e.g. emails, newsletters etc.)

What is being communicated?	To which team/person?	How and when?

BUSINESS CONTINUITY & DISASTER RECOVERY

(Explain the steps the project has taken to ensure the business has the ability to recover they project systems, processes & data from disaster e.g. system failure, data loss, site inaccessibility etc.)

WHAT ARE THE TRAINING REQUIREMENTS?

(Explain the training that will be/has been delivered to support the operational teams and wider stakeholders who will be impacted by this change.)

Role(s)	Training Requirement	Person delivering training	Cost of training

WHAT IS THE LIST OF PRODUCTS THE PROJECT HAS DELIVERED?

(Explain the training that will be/has been delivered to support the operational teams and wider stakeholders who will be impacted by this change.)

Product	Supplier	Service Level Agreement? Y/N	Contract Location?

WHAT SUPPORTING DOCUMENTATION IS AVAILABLE?

(List the supporting documentation, who owns it and where it is stored.)

Product	Supporting Documents	Owner of Documents	Document Location

WHAT HAS THE PROJECT DONE TO ENSURE SECURITY?

Security Officer Sign Off

ACCEPTANCE FROM SUPPORT TEAM

Role(s)	Planned Date of Handover	Success criteria	Sign-off by	Signature

ATC TEMPLATE 05 PROJECT STATUS UPDATE

ATC TEMPLATE 05 PROJECT STATUS UPDATE

Question to answer: How is it going?

(This is an update that is provided by the Project Manager at period end. It is also called the yellow card. Use this information, and information from finance to populate the Executive Dashboard.)

Project Name:	On Time	Y/ N
Project Sponsor (Owner):	On Budget	Y/ N
Project Manager (Captain):	Within agreed scope	Y/ N
	Within risk tolerance	Y/N

Air Traffic Control Stage: (please circle)	1. Is this a good idea (Project Concept)	2. Is the cost/benefit worth it (Business Case)	3. How will we do this (PID the Flight PLAN)
4. Should we do this? (Takeoff /Decision Paper)	5. How is it going? (In-flight/Execution)	6. Is everything ok? (Handover & Close)	7. Did we achieve our aims? (Benefits Review)

WHERE HAVE WE BEEN?

WHATS NEXT ON THE JOURNEY?

ISSUES OR RISKS? (ANY EXPECTED OR UNEXPECTED TURBULENCE?)

DECISIONS NEEDED? BY THE PM (CAPTAIN), PROJECT TEAM (CREW) OR SPONSOR (AIRCRAFT OWNER) OR OTHERS?

KEY RESOURCES (CREW) CURRENT BEING USED? (NAME, SKILLSET AND DAYS PER WEEK/MONTH)

KEY RESOURCES (CREW) NEEDED NEXT? (NAME, SKILLSET AND LIKELY DAYS PER WEEK/MONTH)

ATC TEMPLATE 04 DECISION PAPER

ATC TEMPLATE 04 DECISION PAPER

Question to answer: Should we do this?

(This is a stand-alone document that summarises the Project Idea, Business Case and Project Initiation Document (PID).)

WHAT IS THE CHANGE

Project Name:
Why should we prioritise this change?	(This section is the executive summary which should provide concise details of the issue, the recommended action and expected benefits. Additional detail can be included in supporting documents.) Situation Recommended change Benefits (i.e. the reasons that this merits a decision).
How much time and effort will this take?	(This section should include detail key issues like time and resources - additional detail is needed this can be included in supporting documents.
How does this fit in with our strategy & our change programme?	(How does this change fit into the bigger picture? Please draw a clear link between this change, the strategy and the change programme).

WHAT ARE THE IMPLICATIONS

What are the financial implications?	(This section should detail costs v benefits and note the cash-flow implications. It may be co-authored by the Finance Team who will validate any necessary figures.) Financial Cost Financial Benefit Net Impact Source of funding Cash flow implications
What are the implications for Governance, Audit, Compliance & Risk?	(This section should refer to risks and where relevant refer to the risk noted in the risk log and the risk rating.)
What are the implications for our competitive position and reputation?	(This section should refer to market impact/ customer impact, possibly regulatory or political risk.)
What are the implications for Ops, Health & Safety, Helpdesk & Facilities?	(This section should refer to any changes to equipment, processes and procedures in store/care sites. If there will be an ongoing contractual arrangement with a supplier, this should be detailed here.)
What are the implications for HR, L&D and Training?	(This section should detail any HR implications for recruitment, manpower, costs, roles & responsibilities, training etc.)
What are the implications for IT, Data & Info-Security?	(This section should detail any IT implications on hardware, software, licensing, info-security, data etc. If there will be an ongoing service level agreement or support contract with a supplier, this should be detailed here.)

WHAT IS THE RECOMMENDATION

Recommendation / Action Required	This section should summarize the action or decision which is being sought. This Decision Paper is asking the Exec Sponsor/Team to NOTE the following This Decision Paper is asking the Exec Sponsor/Team to say YES to the following actions
Supporting Papers	This section should summarize any relevant supporting documents or past decisions.

WHAT IS THE DECISION

Actions Agreed / Notes from Meeting

This will be completed from the Minutes of each of the Meeting where discussed so as to provide a record of where the discussion is in process.

GUIDANCE

This is an explanation of the proposed Decision Paper Process
The following steps are proposed.

The template Decision Paper is completed by the author/sponsor. This is then circulated to key stakeholders for their review and approval to ensure that all the information is correct, any supporting papers are appended, and there is consensus on issues and recommendations before the Decision Paper is presented to the next Executive Team meeting.

The draft Decision Paper goes to the Strategy, Projects and Change Office to support and co-ordinate. This is to check that the Decision Paper is properly complete and circulated at least 5 days before the next Executive Team meeting, giving people the opportunity to read and think in advance. The Decision Paper may be classified as secure, confidential or secret and will be held according to that classification.

The Executive Team reviews the Decision Paper and will accept, reject or revise the paper (possibly asking for changes or further information). The Decision Paper and the outcome is then logged/filed with copies to the necessary people to effect agreed actions.

In some cases, following the Executive Team meeting the scale or seriousness of the decision may mean that the Decision Paper is then escalated for a Board decision. This follows a similar process to that described above and offers transparency on the step-by-step process from author > sponsor > Executive Team > Board

This is the proposed criteria for when a Decision Paper might be required:

IF

Less Than 5000	Decision Paper not required
5000 - 25,000	Decision required to be endorsed by Sponsor (line report executive only)
25,000 - 200,000	Decision required to be endorsed by Sponsor and [Organisation Name] Exec
Above 200,000	Decision required to be endorsed by Board

OR
If the Project/Proposal has a significant cross-functional impact on product, process or resources

OR
If the EMT decide there should be a Decision Paper

ATC TEMPLATE 03 PROJECT INITIATION DOCUMENT (FLIGHT PLAN)

ATC TEMPLATE 03 PROJECT INITIATION DOCUMENT (FLIGHT PLAN)
 
Question to answer: How will we do this?

At this step we need a written down detail of implementation plan: roles, goals, controls, tasks, owners, actions.

Process: Consult with the appropriate stakeholders, who will actually participate in the project. Write it all down on template and get agreement from your manager or Executive sponsor.
If you need any help please contact us in the Strategy, Projects and Change Office.

KEY INFORMATION
 

Project Title
Author
Sponsor
Current Date
SPCO Project Code

Why do we want to do this? How is it going to change the business? (Basic background to the project explaining the situation, problem, need, context and priority. This essentially says why this needs to be done.)

WHAT IS THE PROJECT NOT GOING TO DELIVER?
 
(It is important to be clear about what is out of scope. What things are important, but not going to be delivered?)

WHO IS ON THE STEERING GROUP?
 
(List the key internal people who are not involved in the project but need to be informed of this document and the project (resources, time, budget, priority.)

Person	Name & Role
Sponsor (who is ultimately accountable)
Key Supplier (who is delivering the change)
Key Customer (who will benefit from the change)

WHAT ARE THE ROLES OF THE PEOPLE DELIVERING THE CHANGE?
 
(List the key internal people and external people, their roles and responsibilities. Considering who is responsible, accountable, consulted or informed will help to identify the key stakeholder groups for the project.)

	Name(s) & Job Roles	Which part(s) of the project?	Person-days required
Responsible - The person who actually carries out the process or task. Gets the job done.
Accountable who is ultimately accountable for the job being done right. Responsible people are accountable to this person
Consulted people who are not directly involved with carrying out the task, but who are consulted. e.g. subject matter expert or advisor.
Informed Those who receive output from the process or task, or those who need to stay informed.

WHO WILL CHECK & APPROVE THE OUTPUTS OF THE PROJECT?
 
(List the key people who will review, approve & sign-off this document & the project (resources, time, budget, priority)

Person	Role

WHO WILL THE PROJECT OUTPUTS BE HANDED-OVER TO? WHEN?
 
(List the key people who will pick-up the outputs of this project when they are transitioned to Business As Usual)

Person	Role	Any training or support required?

THE PROJECT PLAN WHAT WERE GOING TO DO AND WHEN.
 
(List the key steps, phases, packages of work. This may be a table (as below), form, text, graphic or a Gantt Chart. What it needs to explain is how and when we will do each of the steps, phases and packages of work. It is a detailed summary of tasks, people, actions and dates.)

Item	Description what is it & what does it do?	Who is it for?	Who is building/supplying it?	How many days will this take?	Cost	Who is checking it & signing it off?	Target Date	Status	Comments

RESOURCE PLAN WHAT SKILLS DO WE NEED & WHEN?
 
(What skills do we need and when do we need them? Understanding this will help us allocate people, or secure extra resources by contract, secondment, or other means.)

Internal People

Skill Set Needed e.g. PM, Analyst, Tester, BA etc.	Name of person & current role (if internal)	How many person-days do you need?	When do you need them? (week/period/year)

External People

Skill Set Needed e.g. PM, Analyst, Tester, BA etc.	Name of person & current role (if internal)	How many person-days do you need?	When do you need them? (week/period/year)

FUNDING PLAN HOW MUCH MONEY DO WE NEED & WHEN?
 
(What funding do we need and when do we need it? Understanding this will help us plan & allocate funds.)

Costs

Which elements of the project will cost	How much do we expect to spend?	When do we expect to spend it?	When will we submit a CAPEX request?
	Total:

Income

Which elements of the project deliver the benefit/income?	How much benefit / income do we expect?	When is it expected to come in?	When will we check the benefit has been received?
	Total:
Total Net Benefit:

RISKS WHAT DO WE NEED TO KEEP AN EYE ON?
 
(What could impact the success of the project? What unintended impacts could the project have?.)

Risk	How likely is it to happen (probability)	What would the impact be?	What could/should we do to limit this?	Who should manage this risk?	What is the risk rating in the register?

DEPENDENCIES

What impacts this change? What does this change impact?	How critical is this dependency? (from minor to game-changer) e.g. data verification for member engagement?	Who owns the dependency?	Do they know about this change?