ATC TEMPLATE 02 PROJECT BUSINESS CASE

ATC TEMPLATE 02 PROJECT BUSINESS CASE

Question to answer: Is the cost/benefit worthwhile?

At this step we need a written down detail of strategic aim, cost, benefit in a format acceptable to finance for investment or project appraisal

Process: Get a CAPEX FORM  fill it in. Attach it to the Business Case template and get sign-off from your manager or exec (depending on the value)

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

KEY INFORMATION

Project Title
Author
Sponsor
Current Date
SPCO Project Code

WHICH BU OR FUNCTION IS THIS FOR? WHICH PROGRAMME WILL THIS BE PART OF?

Name of Business Unit, Support Function or Corporate
Strategic Programme

Project Type (tick all that apply)

Capital

Property

IT

Other (specify)

PROJECT SUMMARY

What are the key benefits of this change? (Highlight the key points, which should include important benefits and the return on investment (ROI))

How have your tested/trialed this idea? (Please attach documentation showing any test/trial results or other supporting research)

What other options are available? (Analysis and reasoned recommendation for the base business options of: do nothing, do the minimal or do something)

WHAT ARE THE TIMESCALES?

(The period over which the project will run (summary of the Project Plan) and the period over which the benefits will be realized. This information is subsequently used to help timing decisions when planning (Project Plan, Stage Plan and Benefits Review Plan)

Year	Project Stages (1-7)	Expected Benefits Realised

WHAT ARE THE MAJOR RISKS?

(Give a summary of the key risks associated with the project together with the likely impact and plans should they occur)

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 ARE THE BENEFITS, DISBENEFITS AND COSTS OF THIS CHANGE?

(The benefits that the project will deliver expressed in measurable terms against the situation as it exists prior to the project. Benefits should be both qualitative and quantitative. They should be aligned to programme benefits.

Dis-benefits are actual consequences of an activity (unlike a risk, which is uncertain). E.g. merging two elements of an organization onto a new site may lead to better joint working and lower costs but lead to dis-benefits (e.g. drop in productivity during the merger). Dis-benefits need to be valued and incorporated into the investment appraisal)

Benefits / Disbenefits	Value
Total
Project / One-off Costs	Value
Total
Ongoing / Annual Costs
Total

INVESTMENT APPRAISAL SUMMARY

(The analysis may use techniques such as cash flow statement, ROI, net present value, internal rate of return and payback period. The objective is to be able to define the value of a project as an investment. The investment appraisal should address how the project will be funded)

Heading	Target	Low/Low	Medium/Medium	High/High
Accounting Rate of ReturnDoes the project meet the target return?	12
Payback Period (Years) How long will it take to repay the initial investment?	67 of Life or 10 years
Interest Cover Multiple	2

ATC TEMPLATE 01 PROJECT IDEA SUMMARY (PROJECT BRIEF)

ATC TEMPLATE 01 PROJECT IDEA SUMMARY (PROJECT BRIEF)

Question to answer: Is this a good idea?

At the idea stage we need a written down explanation in a simple form (possibly supported with a market analysis and supplier documentation) outlining strategic aim, cost, benefit for initial evaluation. This allows the team to understand what the project is/is not and whether we want to proceed to a business case.

Please add additional rows to any of the sections as necessary. Only provide summarized information but attach detailed analysis as an appendix if needed.
If you need any help please contact the Strategy, Projects and Change Office (SPCO)

KEY INFORMATION

Project Title
Author
Sponsor
Current Date

WHICH BUSINESS UNIT, FUNCTIONAL OR CORPORATE STRATEGY DOES THIS SUPPORT?

Name of Business Unit, Support Function or Corporate
Strategic Programme

Project Type (tick all that apply)

Capital

Property

IT

Other (specify)

PROJECT SUMMARY

What is this change? (The description should be a clear but brief description of the project. Summarize the size/scale, complexity and expected timescale of this change. In ATC terms, is this a jumbo jet, an aircraft carrier or a small propeller plane?) e.g. This is a full replacement of our central product and price management IT systems

Why do we want to do this? How is it going to change the business? (Think in terms of what is this project doing to meet the aims and objectives of CICS Why are we doing this? What will the business be able to do after this change, that it cant do now?)

What are the key things that we will deliver? (What are the things that will be delivered/complete as part of this? Think of this like a shopping list of tasks or items that need to be completed and that can be allocated to people to deliver. Ideally give an estimate of the time and cost.)

Item	Description what does it do?	Who is it for?	Who is making/ supplying it?	How long could it take?	What is it likely to cost?

WHAT SKILLS ARE WE LIKELY TO NEED AND WHEN?

(Think about this in person days - identifying if the skills are internal from business unit(s), internal from support function(s) or from external suppliers or consultants. You will be asked for more detail in the Project Initiation Document).

Role	Person-days

WHAT DO WE EXPECT THE FINANCIAL COST/BENEFIT TO LOOK LIKE?

(What financial benefit do we expect? You will be asked for more detail in the Business Case).

	Year 1	Year 2	Year 3	Ongoing
Expected Costs
Expected Benefits
Net Benefit/Cost

WHAT ARE THE TOP THREE RISKS AND DEPENDENCIES THAT WE ARE AWARE OF NOW?

(What should the decision-makers consider when looking at this project?).

Risks what are we uncertain about?	Dependencies what does this impact / impacts on this?

AUTHORITY TO PROCEED

Signed By:	Role in Project	Date

ATC MATURITY MATRIX

ATC MATURITY MATRIX

INTRODUCTION

In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.

This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)

ATC MATURITY MATRIX

	Level1	Level2	Level3
Management Control	Project management terminology is used by some members of the organization but not consistently and possibly not understood by all stakeholders. Projects will be conducted and managed according to individual preferences.	The concepts of project management will have been grasped by the organization, and there may be local experts, such as experienced project managers, working on key projects.	There is a centrally defined and documented approach to a project management life cycle and controls, and it is applied in all projects by capable staff who support project teams.
Benefits Management	There is some recognition that the concept of benefits can be differentiated from project outputs.	Benefits are recognized as an element within project business cases. There may be some documentation regarding who is responsible for particular benefits and their realization, but this is unlikely to be followed through or consistent.	There is a centrally managed and consistent framework for defining and tracking the realization of benefits from project outputs.
Financial Management	There is little or no financial control at project level. There is a lack of accountability and monitoring of project expenditure.	Project business cases are produced in various forms and the better and more formal cases will present the rationale on which to obtain organizational commitment to the project. Overall cost of the project is not monitored or fully accounted for.	There are centrally established standards for the preparation of business cases and processes for their management throughout the project life cycle. Project managers monitor costs and expenditure in accordance with organizational guidelines and procedures, with defined interfaces with other financial functions within the organization.
Stakeholder Engagement	Stakeholder engagement and communication is rarelyused by projects as an element of the delivery toolkit.	Projects will be communicated to stakeholders, but this is linked more to the personal initiative of projectmanagers than to a structured approach being deployed by the organization.	There is a centrally managed and consistent approach to stakeholder engagement and communications used by all projects.
Risk Management	There is minimal evidence of risk management being used to any beneficial effect on projects. There may be evidence of risks being documented but little evidence of active management.	Risk management is recognized and used on projects, but there are inconsistent approaches, which result in different levels of commitment and effectiveness.	Project risk management is based on a centrally defined process that is cognizant of the organizations policy for the management of risks and is used consistently.
Organisational Governance	Some informal governance of projects exists but has undefined links to broader organizational controls. Roles are unlikely to be formally defined.	Project management from an organizational perspective is beginning to take shape but with ad hoc controls and no clear strategic control. Roles and responsibilities will be inconsistent, as will reporting lines.	Centrally defined organizational controls are applied consistently to all projects, with decision-making structures in place and linked to organizational governance.
Resource Management	There is some recognition within the organization of the need to manage resources effectively to enable successful delivery of projects, but little evidence of resource acquisition, planning or management.	Resources are being deployed across the organization and individual projects have an approach to resource acquisition, planning or management. However, there is little evidence of consistency of approach.	The organization has a centrally defined and adopted set of procedures and management processes for acquiring, planning and managing project resources.

USEFUL LINKS AND REFERENCES

About Agile
https://www.guru99.com/waterfall-vs-agile.html

About Waterfall and the leading approach to Waterfall which is PRINCE2
https://prince2.wiki/

ABOUT THE BLOG

This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.

ATC MANAGING RISKS AND ISSUES

ATC MANAGING RISKS AND ISSUES

INTRODUCTION

In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.

This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)

ATC MANAGING RISKS AND ISSUES

Risk management responses can be a mix of five main actions transfer, tolerate, treat, terminate or take the opportunity. Transfer for some risks, the best response may be to transfer them. need to be set and should inform your decisions. Treat by far the greater number of risks will belong to this category.

Risk ID	Risk Description	Probability	Impact	Score	Owner	Action Taken	Note
ID No001	A short description	1	3	3	Initials	Tolerate	A short description
ID No002	A short description	2	3	6	Initials	Transfer	A short description
ID No003	A short description	3	3	9	Initials	Treat	A short description
ID No004	A short description	4	3	12	Initials	Terminate	A short description
ID No005	A short description	5	3	15	Initials	Take	A short description
ID No006	A short description	3	5	15	Initials	Tolerate	A short description
ID No007	A short description	3	4	12	Initials	Transfer	A short description
ID No008	A short description	3	3	9	Initials	Treat	A short description
ID No009	A short description	3	2	6	Initials	Terminate	A short description
ID No010	A short description	3	1	3	Initials	Take	A short description
ID No011	A short description	3	1	3	Initials	Tolerate	A short description

ABOUT THE BLOG

This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.

ATC MANAGING PEOPLES TASKS AND WORKLOAD

ATC MANAGING PEOPLES TASKS AND WORKLOAD

INTRODUCTION

In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.

This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)

PLANNING PEOPLES TASKS AND WORKLOAD

Resource planning: who does what, when, is really important. This is essential to be able to manage communication, co-ordination and collaboration

Who	What	Period1	Period2	Period3	Period4	Total
Name001	Tasks	2	1	2	0	5
Name002	Tasks	1	1	2	0	4
Name003	Tasks	1	0	2	0	3
Name004	Tasks	1	1	2	0	4
Name005	Tasks	1	1	2	3	7
Name006	Tasks	1	1	0	3	5
Name007	Tasks	0	0	1	3	4
Name008	Tasks	0	0	2	3	5
TOTALS		7	5	13	12	37

ROLES FOR DECISIONS AND COMMUNICATION

It is useful to think of all the people who need to be involved in communication, co-ordination and collaboration

Responsible: person who performs an activity or does the work.
Accountable: person who is ultimately accountable and has Yes/No/Veto.
Consulted: person that needs to feedback and contribute to the activity.
Informed: person that needs to know of the decision or action.

A COMMUNICATION PLAN

What is said	Who says it	When it is said	What method/medium is used
List of options	List of options	List of options	List of options
Explanation of aim	The sponsor	Before the start	Email
Explanation of approach	The project manager	At the start	Meeting
Explanation of budget	The team leader	During the project	Letter
Explanation of benefit	The customer	At completion	Briefing
Explanation of schedule	The owner	When finished	Presentation
Add more	Add more	Add more	Add more
Add more	Add more	Add more	Add more
Add more	Add more	Add more	Add more

A COMMUNICATION CALENDAR

Period 1	Period 2	Period 3	Period 4	Period 5	Period 6
Newsletter No1	Newsletter No2	Newsletter No3	Newsletter No4	Newsletter No5	Newsletter No6
Briefing No1	Briefing No2	Briefing No3	Briefing No4	Briefing No5	Briefing No6
Meeting No1	Meeting No2	Meeting No3	Meeting No4	Meeting No5	Meeting No6
Report No1	Report No2	Report No3	Report No4	Report No5	Report No6

ABOUT THE BLOG

This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.

ATC MANAGING TASKS AND CHANGES

ATC MANAGING TASKS AND CHANGES

INTRODUCTION

In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.

This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)

WATERFALL DECIDING WHAT IS NEEDED
Waterfall (plan everything up-front eg PRINCE 2) generally uses a Requirements Catalogue.

There should be a catalogue of requirements, categorised as Must-have, Should-have, Could-have, or Would-like (MoSCoW).

Requirement, Explanation/Criteria, Must-have
Requirement, Explanation/Criteria, Should-have
Requirement, Explanation/Criteria, Could-have
Requirement, Explanation/Criteria, Must-have
Requirement, Explanation/Criteria, Must-have

In the Waterfall we always ADD to the list, even changes are an ADDITION which is why time, cost, and risk always go up. We are committed to everything (including the things we now do not want!) and often only get the changes right at the end.

AGILE DECIDING WHAT IS NEEDED

Agile (make it up as you go eg SCRUM) generally uses User Stories which are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }

User stories are often written on index cards or sticky notes and arranged on walls for planning and discussion. As such, they strongly shift the focus from writing about features to discussing them

In the Agile we always AMEND to the list so we only do the work for this period and wait to see what is in the list for the next period. It might be longer or shorter. We are only committed to the work in the current period (usually 2 weeks)

ROLES FOR DECISIONS AND COMMUNICATION

It is useful to think of all the people who need to be involved in communication, co-ordination and collaboration

Responsible: person who performs an activity or does the work.
Accountable: person who is ultimately accountable and has Yes/No/Veto.
Consulted: person that needs to feedback and contribute to the activity.
Informed: person that needs to know of the decision or action.

ATC MANAGING TASKS AND CHANGES

Changes to time, cost, quality, or output can be unwelcome because they impact the project being on-time, on-budget, to-expectation. This is particularly the case when change ADDS to time, cost, risk and problems. However change sometimes can REDUCE time, cost, risk and problems, and possibly improve quality.

WATERFALL AND AGILE APPROACHES TO CHANGE

Waterfall (plan everything up-front eg PRINCE 2) generally records any change to be EXTRA time, cost, risk and problems because we have agreed up-front all those elements and anything else (even a beneficial change) is regarded as EXTRA.

In these circumstances it is really important that there is a clear understanding of the change and the impact on time, cost, risk and problems and approval for the necessary change in budget, schedule or resources.

Agile (make it up as you go eg SCRUM) generally does not have a fixed idea on time, cost, risk and problems and so every change is just accommodated with the aim being to focus only what is needed and reject anything else. This focus means we ADD costs for what is needed, but REMOVE costs for anything else with the net effect that you only pay for what you need and agreed and nothing else.

CHANGE APPROVAL

In both cases it is important that the customer, end-user or owner is able to confirm what is needed and agree the change as well as the implications.

ABOUT THE BLOG

This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.

ATC STEP 7 THE BENEFITS REVIEW PHASE

ATC STEP 7 THE BENEFITS REVIEW PHASE

INTRODUCTION

In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.

This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)

ATC STEP 7 THE BENEFITS REVIEW PHASE

Benefits Review At this step we need to review of outcomes compared to the business case and plan. 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.

Key question are we trying to answer: Did we achieve our aims, on-time, on-budget, to-specification, with low-risk and high-communication?

Process: Make sure you 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. Get this in writing. We have a template for this.

HOW WE BEGIN

At this stage we are at the considering the quotes, specifications, proposals. This is the time when we deciding what we want, can afford, and are able to achieve, but not yet committing to how or when.

CASE STUDY

Jane has finished her project and is looking back to learn lessons (of what went well, as well as what could have gone better) and to find out if the project turned-out as planned.

CLARITY WRITTEN DOWN

There are the questions your idea phase should aim answer

Question 1 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?

Question 2 Did we achieve the aims set out in the Business Case?
Question 3 How did we do against the planned schedule and costs?
Question 4 Did we stay within our original scope or did it creep?
Question 5 Did we achieve our goals within the budget?
Question 6 Was the supplier happy? How did the design & development of the product go?
Question 7 Was the customer happy? How did the handover go?
Question 8 Did we achieve our strategic goals?
Question 9 What can we learn for next time?
Question 10 Is there anything still left to do?

USEFUL LINKS AND REFERENCES

About Agile
https://www.guru99.com/waterfall-vs-agile.html

About Waterfall and the leading approach to Waterfall which is PRINCE2
https://prince2.wiki/

ABOUT THE BLOG

This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.