What should be included in Project Management?

Table of Contents

What should be included in Project Management?


It is fair to say that people value elements of Project Management differently.

Some like a formal approach with strong Governance, good Documentation, clear Roles, Goals and Controls and transparently as regards who is Responsible, Accountable, Supportive, Consulted, and a clear definition of what is to be Delivered and what constitutes “Done”.

Others see all this as bureaucracy and to grossly paraphrase the Agile Manifesto value the following…

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

In this article I’m not going to compare and contrast methodologies (which I have done in a previous article) but instead suggest that a menu approach may be best for clients to pick which elements they value and are prepared to pay for.

Moreover, a menu approach also allows for greater transparently about the allocation of project roles and responsibilities between the in-house team(s), the supplier-vendor team(s) and the project or change management team(s).


Small to medium sized businesses are unlikely to have full-time project or change managers, or indeed a Project Management Office (PMO) as a group or department that defines, maintains and ensures project management standards across an organization.

For many businesses large-scale change is something that may happen every 3-5 years or possibly once or twice per career depending on the industry. So it makes sense to hire people to support whatever people, process or technology change you are planning.

I’ve suggested that there are 3 teams, but there may be more and roles may be combined. What I think is important is that we are clear who does what and there is no duplication, error or omission.

In-house team

The in-house team will be the people who define the requirements and take delivery of the outputs. Without doubt they will be supported by the supplier-vendor team(s) and project or change management team(s) but the key point is that they are in control as architect and owner of what gets built. The in-house team strength is in knowing what the business wants and needs and coordinating the necessary resources for the project, including defining needs, testing, training, acceptance and use.

Supplier-vendor team

The supplier-vendor team will be the product or service expert, but they need to deliver to the business requirements, standards, and needs set by the in-house team. The supplier-vendor team strength is in knowing the product or service and how to configure and use it to satisfy the understood needs of the customer.

Project or change management team

The project or change management team exist to support the in-house team who may be unfamiliar with process of project and change management, lack the capacity to manage all the tasks, and need someone to anticipate issues and avoid pitfalls that can be costly, time-consuming and disruptive. Moreover the or change management team can add value as a catalyst business process improvement or innovation, as well as be a resource to up-skill the in-house team, improving capacity and capability. The project or change management team strength is in their experience and capacity to support both in-house team (defining) and supplier-vendor (delivering) and end-users (adopting and benefitting)


Let’s provoke this discussion with a simple example: The budget.

The Supplier-vendor view of the budget may centrally be focussed on the contract price and the invoices.

The In-house view of the budget might consider revenue costs, capital costs, Supplier-vendor (product) costs and other costs for example the hire of temping staff or possibly a Project or change management team. Their focus is likely to be on payment of invoices, possibly cash-flow and maybe the Return on Investment [ROI], although in my experience most small business rarely look beyond the payment of invoices.

The Project or change management team can look at, support and manage all of the above depending on the agreed roles and scope. Aside from offering extra capacity, this team can look at value for money, matching payments to products (useful for accountability and ROI) and ensuring proper completion and acceptance before authoring payment. A good Project or change management team can also make projections and suggest savings and opportunities as regards design, delivery and use.

In this example you can see all sorts of different ways and roles to set, monitor, and manage the budget from the simple to the complex.

I will expand upon this wit an exploration of roles and artefacts ostensibly as a menu from which to pick.


In a previous article I have outlined the Pros and Cons of Waterfall, Agile or Hybrid Approach with a bias toward being practical according to the culture, structure and resources in the client organisation. Below I have summarised key roles which are useful to debate. I don’t think that every project should have every role, and I am the first to acknowledge that in most projects a few people will have separate roles.

What I am advocating is that consideration is put to who is Responsible, Accountable, Consulted, Informed, if these roles are needed and who should exercise them.

The following are the roles defined in PRINCE2 (Waterfall):

1. Project Board, a group of the following roles:
a. Executive, the business-oriented person who’s ultimately responsible for the project
b. Senior User, one or more people who represent the final users’ requirements in the board
c. Senior Supplier, one or more people who represent the interests of the suppliers

2. Project Assurance, assures the interests of the primary stakeholders
3. Change Authority, decides on some of the request for changes in behalf of the Project Board
4. Project Manager, responsible for the day to day management of the project in behalf of the Project Board
5. Project Support, helps the Project Manager in project management activities
6. Team Manager, one or more people responsible for ensuring the quality and other variables of production in the teams

The following are the roles defined in Scrum (Agile):

Product owner – The product owner represents the stakeholders of the project. The role is primarily responsible for setting the direction for product development or project progress.

Team lead/Scrum master – The Team Lead or Scrum Master ensures team coordination and supports the progress of the project between individual team members. The Scrum Master takes the instructions from the Product Owner and ensure that the tasks are performed accordingly.

Development team members – The team members within the Development Team are comprised of individuals with responsibilities including but not limited to product development. The team takes cross-functional responsibilities necessary to transform an idea or a requirement into a tangible product for the end-users. The required skills might be wrapped up in one or more dev team members:

1. Product designer
2. Writer
3. Programmer
4. Tester
5. UX specialist

Stakeholders – The Stakeholder position may not be directly involved in the product development process but is used to represent a range of key roles that impact the decisions and work of the Scrum team. The stakeholder may be:

1. The end user of the product
2. Business executives
3. Production support staff
4. Investors
5. External auditors
6. Scrum team members from associated projects and teams

I have included useful references at end for further detail


Below is a list of the PRINCE2 artefacts. I don’t think that every project needs every tool and I am the first to acknowledge that many can be ignored or combined to make the whole process simpler and less bureaucratic and costly. Nonetheless a look at this like can be thought provoking albeit potentially overwhelming for the In-house or Supplier-vendor teams.

Business Case

Business Case
Benefits Management Approach
Experienced Based Co-Design
Stakeholder Engagement
End to end path & Partnerships
Delivery of big projects


Communication Management Approach
Core Groups
Advisory Group
Consumers & Carers
Co Design Groups
Co Design Teams


Quality Register
Quality Management Approach
Key Performance Indicators
Research & Pilots
Review current practices & pathways
Review ideal practices & pathways
Reduce Waste
Use Lean Method of redesign & change practices, concepts and Principles
Identify Best Practice
Stakeholder Engagement
Underpinning Values


Project Product Description (part of Project Brief and refined in the PID)
Product Breakdown Structure (minimum requirement)
Product Description
Product Flow Diagram
Identify core values
Problem Solving using key stakeholders
Goals of care & Plans for care
Standardised education packages
Train the trainer workshops
Value Stream Mapping
Focus Group
Control Trials


Risk Register
Risk Management Approach
Risk Mitigation


Issue Register
Change Control Approach
Consumer Engagement
Tool Refinement
Records approval


Baselines for progress control: Project, Stage and Team Plans
Review: Issue Register, Product Status Account, Quality Register, Risk Register
Reporting: Checkpoint Report, Highlight Report, End Stage Report, End Project Report


These are the main scrum artifacts…

1. Product Vision
The product vision is the long-term goal of the project or product. It is the artifact you will define to set the overall direction of the project or product. The scrum team will use the product vision as a guide.

2. Product Backlog
A product backlog is a list of everything that needs to be achieved on a project, broken down into individual items. This is where the baseline requirements of every feature needed for the end product are prioritized by the product owner for the scrum team.

3. Sprint Vision
The sprint vision or sprint goal is often not defined as an artifact, it is still an important part of the scrum framework. The sprint vision is what the scrum team comes up with when planning a sprint. It provides guidance to the scrum team as to why they are investing their time, money and effort in the sprint.

4. Sprint Backlog
The sprint backlog is the part of the product backlog that the team will be working on in their sprint. Think of it as the to-do list for the sprint.

5. Definition of Done (DOD)
The definition of done (DOD) means that all aspects of a user story have been completed in a sprint backlog. The scrum team must have a shared idea of what being done means. They should create a definition of done and use this as a checklist as they work on their user stories.

6. Product Increment
This is the most important scrum artifact. The product increment is all the product backlog items that have been completed during a sprint.

7. Burndown Chart
Though not always considered part of the essential scrum artifacts, the burndown chart is important not to neglect. It is a graphic that shows how fast the team is completing the user stories or items on the product backlog. Therefore, a burndown chart is illustrating the total effort against the amount of work for a sprint.

I have included useful references at end for further detail


Neither PRINCE2 nor SCRUM talk about the following….

Design Authority

A design authority is a body put in place to manage, track, and fulfill project progress more holistically. The design authority evaluates all elements of a project—cost, skill and resource requirements, potential security concerns, feasibility, and more—from every angle.

I have use a Design Authority as a body of Senior Team and/or Experts to review and make recommendations to the Project Board (and though them to the Supplier-vendor team) for any config, process, design or set-up that has a global on the product or service.

In simple terms this ensures that proposals are suitable, feasible and acceptable to the whole business and is a forum for discussion and compromise where necessary to streamline and standardise elements.

Coaching / Mentoring

Very often projects provide an learning and growth opportunity for participants and there may be value in some upskilling, and skills transfer between Project or change management team and in-house team. Coaching / Mentoring may be directly linked to personal development plans or project goals.

Change Teams

As an extension of Coaching / Mentoring very often businesses might set-up a Change Team, Leadership Team or similar. This may be run as a mini-MBA or linked to Chartered Management Institute competencies, study and credentials which extend beyond project delivery to support broader organisational change capability.

Business Process Improvement

People, process and technology change misses an opportunity and forgoes a potential benefit if it does not look at Business Process Improvement or review the Target operating model. A review of Business Process may use tools from Lean, Six-Sigma, Kaizen to reduce waste, improve quality, reduce cost and add customer value.

Target operating model

Target operating model is a description of the desired state of the operating model of an organisation. When working on the operating model, it is normal to define the “as is” model and the “to be” model. The target operating model is the “to be” model.

The scope of the target operating model may include…

P – processes and capabilities;

O – the organization, i.e. the people that are needed to run the processes or deliver the capabilities, and the organisation structure, accountabilities, incentives and culture that will support and nurture these people;

L – the locations, buildings, infrastructure and other assets and resources needed inside the organisation to support the processes and capabilities;

I – the information systems and other cross-organisation or cross-location links needed to support the processes and capabilities, especially the software applications that are needed to process the information;

S – the suppliers and business partners needed outside the organisation to support the processes and capabilities and the types of agreements between this organisation and these partners.

M – the management systems and processes for developing strategy, planning, setting targets, managing performance and continuous improvement.

Key Communications

Both PRINCE2 and SCRUM have artefacts for communications and update. I like to keep these short as Key Communications so rather than a long Newsletter this becomes a short and topical bulletin.

These project bulletins (at least monthly) that explain what is planned for the period ahead, and what (if anything) is expected of project participants. They are sent by Teams and also may be found on the SharePoint site for easy reference.

They are be indexed (Key Communication (KC001, KC002, KC003 etc.) so readers can look back at any past updates and the intention is that they are available to share, which we encourage to help communication, coordination and collaboration.


In 30 years of Project Management, I have never used all of these. Indeed, my experience is that documentation follows dialogue and should be minimalist. The point is to reach agreement and then honour that agreement through the steps

1. Discuss
2. Design
3. Document
4. Develop
5. Demo
6. Deliver

If it is not written down….

If it is not written down how to we know?
If it is not written down did it happen?
If it is not written down how can you test or evaluate?
If it is not written down how can you be sure?
If it isn’t written down properly, you’re not sure exactly what happened.
If the records are not correct, neither is the product.

The sole purpose of documentation should be to support communication, coordination and control and should be as little as is necessary to achieve this.


Without doubt the above may be overwhelming for the in-house team in the same way a cupboard full of ingredients may seem confusing to a novice cook or a bag full of carpentry, electrical and plumbing tools may too much for the average customer of B&Q.

This is perhaps best targeted at the Project or change management team as a tool for discussion when considering what should or should not be included in Project management and agreeing with the client what is needed and who should be responsible.

It might however be amiss to omit my list of preferred components, which include …

Contract Review To be clear on aim, scope, price, roles, requirements etc,
Project Initiation Documents To be clear on roles, goals, controls, tasks, budgets, processes, governance
Project Plan To be clear on deliverables, tasks, dates, milestones, resources
RAID – Risks, Assumptions, Issues, Dependencies To be clear on Risks, Assumptions, Issues, Dependencies and necessary ownership, action or mitigation
Project Budget To be clear on capital, revenue budget, spend, projections, outcome, (and possibly cash flow and ROI)
Communications Plan To be clear on what is said by whom, when, to whom, why, and for what purpose
Stakeholder Management Plan To be clear on who is responsible, accountable, consulted and informed and the best way to engage and support these people
User / Business Requirements Documentation To be clear on the business need, functional requirement, technical standard and acceptable outcome for each key element to be delivered
Deliverables Schedule To be clear on what will be delivered when, plus associated roles to define, agree, review and approve, and mechanism for payment
Weekly Project Update (Overall what’s done, next, issues, decisions) To be clear on general (high-level) tasks, progress, problems, next steps, resources
Weekly Workstream Technical Update (Tasks and Actions) To be clear on detailed-level tasks, progress, problems, next steps, resources
Monthly Project Board / SteerCo To be clear on project governance, performance and progress and address any key issues or decisions
Key Comms / Newsletter A tool to ensure people know what is happening and how it affects them and what action to take
Design Authority / Stakeholder Updates A forum to ensure all the people responsible, accountable, consulted and informed have input and update on design and delivery decisions
Project Assurance Meeting and Report A forum to independently review governance, progress, risk and performance and intervene where necessary
Budget Update To update and if necessary alert on capital, revenue budget, spend, projections, outcome, (and possibly cash flow and ROI)
Risk Update To update and if necessary alert on Risks, Assumptions, Issues, Dependencies and necessary ownership, action or mitigation
Test Plan (Roles, Dates, Process) To be clear on testing roles, goals, dates, test process, fix and retest process, scoring and success criteria
Test Scripts (Tests) To be clear on business, functional, security and other tests necessary to be OK for acceptance, hand-over and use
Test Monitoring / Results & Review To update and if necessary alert on tests, test-progress and readiness for hand-over operational use
Agree Training Requirements To be clear on who needs what training, for which roles, as well as who will do the training, provide the guides and be available to support
Training Sessions and Documentation To be clear on the scope, content, format of training guides, processes, documentation for different roles, users and responsibilities
Agree Hand-over Requirements To be clear that everything is complete, working and ready for hand-over and control the transition of responsibility and ownership
Lessons Learned To be clear on lessons throughout and after the project which will aid future steps and future projects
Benefits Review To be clear on the benefits, compared to the initial plan and to what extent these have been realised or exceeded

As regards structure, my preference is for the following, albeit adding some elements of Scrum Master into the Project Management function within the Project Delivery Team, and some elements of Change Management within the Project Assurance function.

A Project Board or Steering Committee
Design Authority (as discussed above)
A Project Delivery Team (comprising in-house, Supplier-vendor team and others)
Project Assurance providing independent oversight over all the above

This is not exhaustive, because as this article suggests, different components and tools will be needed according to the project. An office move for example is unlikely to require data-migration or need to consider information security or data protection.


If you have enjoyed this you may like the following…

The Pros and Cons of having a methodology

Mediation, facilitation and team building

Why you need project assurance to look at your contract (and not just a lawyer)


An experienced Management Consultant and Project Manager, used to working with people and teams in complex legal, regulatory, and technical environments.

• Management Consultant MBA
• PostGrad International Compliance Association
• PostGrad EC Competition Law
• APMG Change Practitioner
• PRINCE2 Project Manager
• Data Protection Officer (GDPR Practitioner)
• International Coaching Federation ICF Trained Coach
• IoD UK Business Mentor
• Chartered Management Institute Tutor for Level 3,5 & 7
• Experienced team and change facilitator

I have more than 30 years’ experience delivering projects, programme and change and have gathered many tools, templates and tips for every type and scale of project. I love drinking coffee and exchanging ideas, so if you need anything please feel free to message me.

Follow me on a journey exploring new ideas and opportunities @timhjrogers #timhjrogers

Tim HJ Rogers
MBA Management Consultant + Change Practitioner
ICF Trained Coach, IoD Business Mentor, Mediator
PRINCE2 Agile-Scrum Projects, Programmes and PMO
Mob 447797762051


We offer #consulting, #coaching, #mentoring, #facilitation and #mediating to support individuals, teams and organisations through #change. We understand #data, #technology and #process and support #people to drive #performance and #progress for #purpose, #profit and #planet.


Agile Roles & Responsibilities

The 7 Scrum Artifacts: Definitions & Examples