Author: timhjrogers

Table of Contents

INTRODUCTION
THE VARIOUS TEAMS
WHO DOES WHAT?
PROJECT ROLES
PRINCE2 PROJECT COMPONENTS AND ARTEFACTS
SCRUM PROJECT ARTEFACTS
CHANGE AND COMMUNICATION ARTEFACTS
ARTEFACTS CONCLUSION
CONCLUSION
OTHER READING
ABOUT THE AUTHOR
REFERENCES AND RESOURCES
What should be included in Project Management?

INTRODUCTION
GoTop

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).

THE VARIOUS TEAMS
GoTop

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)

WHO DOES WHAT?
GoTop

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.

PROJECT ROLES
GoTop

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

PRINCE2 PROJECT COMPONENTS AND ARTEFACTS
GoTop

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
Governance
Stakeholder Engagement
End to end path & Partnerships
Delivery of big projects

Organisation

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

Quality

Quality Register
Quality Management Approach
Key Performance Indicators
Research & Pilots
Feedback
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

Plans

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

Risk Register
Risk Management Approach
Risk Mitigation

Change

Issue Register
Change Control Approach
Publication
Resources
Processes
Activities
Consumer Engagement
Workforce
Tool Refinement
Records approval

Progress

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

SCRUM PROJECT ARTEFACTS
GoTop

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

CHANGE AND COMMUNICATION ARTEFACTS
GoTop

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.

ARTEFACTS CONCLUSION
GoTop

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.

CONCLUSION
GoTop

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.

OTHER READING
GoTop

If you have enjoyed this you may like the following…

The Pros and Cons of having a methodology
https://www.adaptconsultingcompany.com/2023/01/04/the-pros-and-cons-of-having-a-methodology

Mediation, facilitation and team building
https://www.adaptconsultingcompany.com/2023/01/03/mediation-facilitation-and-team-building/

Why you need project assurance to look at your contract (and not just a lawyer)
https://www.adaptconsultingcompany.com/2023/01/02/why-you-need-project-assurance-to-look-at-your-contract-and-not-just-a-lawyer/

ABOUT THE AUTHOR
GoTop

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 Tim@AdaptConsultingCompany.com

FOLLOW *ADAPT CONSULTING COMPANY* https://www.linkedin.com/company/adapt-consulting-company

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.

REFERENCES AND RESOURCES
GoTop

Agile Roles & Responsibilities
https://www.bmc.com/blogs/agile-roles-responsibilities/

The 7 Scrum Artifacts: Definitions & Examples
https://www.projectmanager.com/blog/scrum-artifacts

Table of Contents

INTRODUCTION
METHODOLOGY
AGILE AND WATERFALL
AGILE EXAMPLE: SCRUM
WATERFALL EXAMPLE: PRINCE2
SCRUMMER-FALL
IN-HOUSE METHODOLOGY
METHODOLOGY AND CULTURE
ROADMAP, FLIGHT-PLAN OR JOURNEY PLANNER
CONCLUSION
ABOUT THE AUTHOR
REFERENCES AND RESOURCES

The Pros and Cons of having a methodology

INTRODUCTION
GoTop

Is a methodology prescriptive, restrictive, or facilitative? Perhaps methodology is just a different form of persona, culture, identity or ways of working that may change according to circumstance.

In this article I explore methodology as a framework, tool-bag and process.

METHODOLOGY
GoTop

Methodology is defined as a system of methods used in a particular area of study or activity. In its most common sense, methodology is the study of research methods. However, the term can also refer to the methods themselves or to the philosophical discussion of associated background assumptions. A method is a structured procedure for bringing about a certain goal

If building a methodology should this reflect yourself, your style, your persona or perhaps that of your client, or maybe the supplier-vendor and product. For example, should your methodology be different for a retail, financial, charity or other industry or sector? Should your methodology be different when delivering different products: perhaps different for a roll-out of Product A or Product B reflecting both the nature of the product and possibly the culture of the supplier-vendor?

AGILE AND WATERFALL
GoTop

The key difference between Agile vs. Waterfall is that Waterfall breaks down software development into isolated phases that flow into each other, while Agile advocates iterative development cycles in which multiple lifecycle phases can run in parallel.

It is beyond the scope of this paper to go into detail of each, but it may be worth summarising as part of a broader discussion about methodology.

A Waterfall (PRINCE2) approach to packing might be used if kayaking in the Greenland wilderness. Anticipate every possibility and pack accordingly because failure to plan is planning to fail, and forgetting something like a sleeping bag may be the end of you, as well as your holiday!

An Agile (Scrum) approach to packing might be used if travelling in India where it may be better to simply bring money and buy what you need, when you need it, depending on the circumstances. No point in having more clothing and equipment than you actually need, it will slow you down and cost you more than necessary.

AGILE EXAMPLE: SCRUM
GoTop

Agile development methodology and testing practices have worked wonders for several organizations with positive aspects. The positive aspects of agile are not hidden. They are very much visible in organizations. There are some of the important points related to the agile model listed as follows

1. Agile focuses on customer feedback, collaboration, small and rapid releases.
2. Its purpose is to manage complex projects.
3. The Agile produces better application suites with the desired requirements. Moreover, it can quickly adapt according to the changes made on time during the project life.
4. It has a small team size. Therefore, fewer people work on it so that they can move faster.
5. The agile model is not a suitable model for small projects. The expenses of developing the small projects using agile are more than compared to other models.
6. In agile methodology, the interaction of customers is very high, as after each iteration an incremental model is deployed to customers.

I have not included a list to all the Scrum roles, processes, tools and templates but have included links to further reading at the end.

WATERFALL EXAMPLE: PRINCE2
GoTop

It is one of the easiest and traditional model to manage. Because of its traditional development nature, each phase has specific deliverables and a review process. The waterfall model works well in smaller size projects where requirements are easily understandable.

The waterfall model is a universally accepted model. In this method, the whole process of software development is divided into various phases. The development in the waterfall model is seen as flowing steadily downwards (like a waterfall) as it is a continuous software development model. This model is named “Waterfall Model”, because its diagrammatic representation resembles a cascade of waterfalls. Some important points related to the waterfall model are listed as follows

1. Waterfall model is not an ideal model to develop a large scale project size.
2. The requirements in the waterfall model should be clear cut at the beginning time; otherwise, it may lead to a less effective method.
3. In the waterfall model, it is hard to move back in order to make changes in the previous phase.
4. The testing process in the waterfall model starts after the completion of development. So, there is a high chance of bugs to be found later in the project development.

I have not included a list to all the PRINCE2 roles, processes, tools and templates but have included links to further reading at the end.

SCRUMMER-FALL
GoTop

In my experience as a Project Manager there are merits in each and often a hybrid approach is best according to the client, circumstances, product etc. I liken a methodology to a toolkit and you might pick different tools under different circumstances.

I have often combined the elements of Scrum master and Project manager, and accommodated both Product Owners and Sponsors.

While a Scrum master makes sure their team follows Scrum principles, Project managers oversee the entirety of a project, including logistics like budget and risk. Scrum Masters can be project managers, and project managers can be Scrum masters, but they’re not the same thing

The Project Owner is the individual responsible for the completion of the project on time and on budget. The Project Sponsor is an important stakeholder for the project that has resources invested in the project. The project’s completion typically benefits the Project Sponsor.

IN-HOUSE METHODOLOGY
GoTop

Where a methodology can be useful is as a way of explaining a step-by-step process that the organisation understands and follows. However, describing a step-by-step process need not be prescriptive about tools, templates or documents.

PRINCE2 suggests the following logical sequence, but I like to customise this to suit the organisation terminology, structure and governance taking account of existing roles, committees, forums and processes for decision making, funding etc.

1. Starting up a Project
2. Initiating a Project
3. Directing a Project
4. Managing a Stage Boundary
5. Controlling a Stage
6. Managing Product Delivery
7. Closing a Project

METHODOLOGY AND CULTURE
GoTop

Making the methodology fit with the in-house process and culture greatly eases understanding and adoption. Indeed, it may facilitate a broader and useful dialogue about -house process and culture, improving the organisations delivery capacity and capability.

I might suggest that methodology needs to fit culture, but since both are “the way we do things around here” methodology IS culture and misalignment or incompatibility is likely to cause friction.

The culture of and working practices of a regulated financial business are likely to be different from a fast-moving retail business. The process involved in an office relocation will be different to software development. The ways of working for a product lead supplier-vendor operating out of Malaysia and will be different from a service-lead supplier-vendor operating in the US or UK.

ROADMAP, FLIGHT-PLAN OR JOURNEY PLANNER
GoTop

The point is that methodology is a tool for communication (we understand where we are in the process) and a tool for control (we understand the roles, goals and process).

Roadmap

An often used term is that of a product roadmap. This is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short and long-term goals for the product or project, and how they will be achieved.

Your methodology may simply be a roadmap of checkpoints along the way to a destination.

Flight-plan

As a coach I often use metaphors as a way to explore topics from a new perspective and unlock new thinking. One day I said… “Well if you were going on holiday you’d have a plan for where you are going, a list of ideas and activities to do when you get there, and enough money and time-off to be able to enjoy the experience”.

This metaphor stuck and grew as the thinking strategy for a technology change programme for a retail business. It is simple in its concept, but powerful because everyone has an experience of travelling and its gives people agency and common sense to their approach to achieving things that is sometimes lost in the complex ‘project speak’.
Key concepts…

1. Project Management Office = Air Traffic Control [ATC]
2. Project = Plane
3. Sponsor = Plane Owner
4. Project Manager = Pilot
5. Project Delivery Team = Crew
6. Stakeholders & Participants = Passengers
7. Budget = Fuel

Key processes…

1. Destination
2. Passengers and crew
3. Pre-flight checks
4. Taxi to the runway
5. Permission to take-off
6. Flying
7. Diversion
8. Landing
9. Disembarking
10. Arriving

I have written about this at length in another article ATC Project Management.

Journey Planner

For one organisation we used a London Underground style map to indicate a variety of routes and stops that may be taken on a change management journey. Perhaps for one project, programme or change initiative we pause at Coaching, Procurement, Training but for others we take a different route with different passengers to another destination via Outsourcing.

The advantage of the London Underground style map is that it can have clear checkpoints, stops or interventions but it is not prescriptive of the journey that you take or the order in which you visit these stations.

CONCLUSION
GoTop

I think it is useful to be flexible about methodology and the sign of a good project manager is the ability to pick the right tools for the task. I do however feel that it is useful for everyone to have a common understanding to aid communication, collaboration, coordination and control. So whilst I am relaxed about which methodology, and am flexible to create one where necessary, I do feel organisations going through change should have one.

ABOUT THE AUTHOR
GoTop

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 Tim@AdaptConsultingCompany.com

FOLLOW *ADAPT CONSULTING COMPANY* https://www.linkedin.com/company/adapt-consulting-company

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.

REFERENCES AND RESOURCES
GoTop

Difference between Agile and Waterfall model
https://www.javatpoint.com/agile-vs-waterfall-model

INTRODUCTION

Facilitation and Mediation promotes listening and understanding. It encourages a mutual solution focus, and Mediation, in particular, repairs and rebuilds collaboration, communication and trust and will deliver better outcomes. 

Below I have substantially used the term Mediation, because as well as being a facilitator I am qualified Mediation practitioner and although the skills and approaches and benefits are similar, Mediation is less well understood or used, possibly because it is seen as a sign of failure rather than a methodology for success.

Throughout, think about how these approaches can be used to set-up teams and support the thorough for forming, storming, norming and performing processes of establishing roles, goals and controls, plus rules, rituals and recognition. 

FACILITATION

A facilitator is a person who helps a group of people to work together better, understand their common objectives, and plan how to achieve these objectives, during meetings or discussions. In doing so, the facilitator remains “neutral”, meaning they do not take a particular position in the discussion

MEDIATION

Business Mediation is an effective method for conflict resolution. It is successful between around 80% of the time. Parties discuss their disputes facilitated by an impartial third person(s) who supports them reaching a mutually agreed outcome. 

It can be better than alternatives including court litigation, arbitration or ombudsman decision because is inherently less adversarial, less expensive, and less stressful and confidential allowing for a flexible process which may help to preserve relationships. 

People are far more likely to stick to an agreement reached in mediation because people place a high value and greater ownership in outcomes they shared in creating

We can see here useful tips for teams, not least the Ikea Effect that people will be more committed to roles, goals and controls, plus rules, rituals and recognition if they have been participant in their creating.

WHY IS MEDIATION WORTHWHILE?

The problem with arguing is that it seldom resolves the problem and legal action may win a battle, but ultimately distract, disrupt and damage the relationships, undermining any future work together. 

Any loss of confidence and trust is likely to be damaging to people and the delivery of projects, products and performance.

Mediation promotes listening and understanding. It encourages a mutual solution focus, and therefore repairs and rebuilds collaboration, communication and trust. Success in Mediation will often improve relationships, support agreement and deliver better results. 

A COMMERCIAL PROJECT CASE STUDY

A client is unable to clearly define and document their requirements but expects that the supplier will provide a standard product that satisfies all their needs. The supplier provides services for many clients and markets and they all vary depending on country, currency, customers. They expect the client to be able to decide quickly and clearly the exact specification and configuration they require. 

As time progresses costs escalate and discussion continues and frustration builds because time, money, and effort is being consumed but outputs and outcomes are behind schedule, ahead of costs and short of expectations.

The client sees their project, product or performance at risk and the supplier sees their profit margin erode and resources tied-up far longer than expected compromising other customers and contracts.

Both parties experience considerable stress upon their people and compromise to plans and operations.

SO WHAT CAN A MEDIATOR DO TO HELP?

There are four primary styles that are used by mediators today

1. Facilitative (does not give advice), 

2. Evaluative (making recommendations or providing opinions), 

3. Transformative (seeks to empower each of the parties in order to transform the relationship) 

4. Narrative (to merge their experience into a new shared story with a better outcome)

CASE STUDY

An approach to a mediation between two commercial business over a dispute on the supply of services and the cost of work.

Note all cases are as different as the people involved in them and this is not a prescription per-se but instead an indicative structure. In reality any mediator will take time to understand the parties, the issues and the context and design an approach that takes account of these essential elements.

Below are the steps that might be taken.

Step 1 – Each partly writes down for themselves, privately [1] how the see the situation [2] how it has affected them [3] how it has affected the other party [4] what they want to achieve or do differently following the mediation

Step 2 – Each partly meets and gets 5 – 10 minutes uninterrupted to state their views human to human in a room (or if necessary Zoom call). If necessary use mediator/moderator to manage the time and content to keep things on-track (but allowing room for people to express their feelings)

Step 3 – Each partly then gets enough time to propose “new ways of working” and what action to take if we feel we are at risk of slipping back to old ways. A mediator/advisor can record all the positive suggestions for later review (at Step 4)

Step 4 – Privately each partly now reviewed their Step 1 assessment based on the discussion at Step 2 & 3, if necessary in private consultation with a mediator/advisor

Step 5 – A settlement is sought, either between the two parties face-to-face, or using an middle person as an intermediary (Note1)

Step 6 – A short note, charter, contract or agreement is drafted to “close” the matter, agree the positive future focus and move forward.

Note1: The middle person never recommend a figure but simply says higher or lower to each party until they are within a “comfort zone” Example Person-A settlement range may be £50k to £100k whereas Person-B settlement range may be £25k to £70k. The “comfort zone” is £50k to £70 and anywhere in this range would be acceptable. Note it may not be all about money. There are lots of offers or concessions that can be made instead of cash. 

HOW DOES THIS WORK?

The process can go as quickly as the parties wish because they are the people who decide what needs to be discussed, decided and documented on the way to agreement. There is no waiting for court dates or other delay, disruption or distraction.

Key factors for success

1. Select the right Neutral.

2. Preparation, preparation, preparation.

3. Identify all “big picture” issues and contemplate impasse points.

4. Set expectations for the parties prior to mediation.

5. Do not underestimate emotions.

6. Be prepared to draft a Settlement Agreement or Memorandum of Understanding before the mediation concludes.

7. Advise the parties that a full mediation may advance negotiations but could require ongoing conversation to complete the settlement.

Success comes from managing the feeling and the thinking environment. 

• There are five domains to consider for Feeling Environment: Status, Certainty, Autonomy, Relatedness, And Fairness. Certainty concerns being able to predict the future. Autonomy provides a sense of control over events. Relatedness is a sense of safety with others. 

• The ten behaviours that generate Thinking Environment are: Attention, Equality, Ease, Appreciation, Encouragement, Feelings, Information, Diversity, Incisive Questions, Place.

In the event of an unsuccessful mediation, the parties can still go to court or arbitration. However, in this event, they do so being better prepared, having focused upon the real issues in dispute between them. 

We can see here useful tips for teams: Status, Certainty, Autonomy, Relatedness, And Fairness is really important for people to want to participant and engage. The ten behaviours that generate Thinking Environment are critical to the quality, output and outcome of the group. 

ABOUT THE AUTHOR

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 Level3,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 Tim@AdaptConsultingCompany.com 

FOLLOW *ADAPT CONSULTING COMPANY* https://www.linkedin.com/company/adapt-consulting-company

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.

TYPICAL SCENARIO

The business gets to the end of the procurement phase, agrees the contract, budget and start-date and then appoints a project manger to coordinate the plan and resources and oversee the implementation.

THE POSSIBLE PROBLEMS

Very often the initial request for proposals or invitation to tender is less than perfect because at this early stage the client may know what they want, but not necessarily the best tool or method to achieve this. The procurement phase is really one of discussion rather than design.

The contact will doubtless outline what the supplier-vendor sees as the key issues, generally ignoring elements which are non-standard which “can be discussed later”. Moreover there may be all sort of assumptions and dependencies that both parties don’t fully appreciate. 

The contract may be vague about the implementation and instead focus on the product with the consequence that whilst some elements may be fixed the variable cost may be unspecified and significant without an agreed mechanism to anticipate, manage and control.

The latter two elements combine where there is any ambiguity of who does what. For example the split of work between the supplier-vendor and client for training, testing, documentation, meetings, design and decision. At one extreme each party maybe expecting the other to resource this, with consequential impact on time, scope and costs if expectations differ.

CASE STUDY

Organisation A contacted for what they anticipated was substantially an industry standard off-the-shelf solution from supplier-vendor B. When it come to delivery a huge amount of time & materials costs was escalating and at 30% of the project they were at 90% of the budget.  

Organisation A felt that they were being unnecessarily charged for work which was standard and should be included in the contracted costs, and certainly not escalating unchecked. Moreover it was impossible to reconcile these costs to a product delivered and working. 

Supplier-vendor B felt that each installation was different according to the needs, standards, processes of the client and it was the clients responsibility to be clear, succinct and specific about their requirements up-front and the time in discussion, debate, design was rightly the clients choice and expense.

The contract was not specific about payment, complaint or mediation mechanisms. For example: Payment on completion or acceptance; Definition of “done” or other success or acceptance criteria; Need to project future costs rather than report historical past costs (Leading to uncertainty about end-costs). 

The above is a combination of experiences rolled into one case study to illustrate and keep the parties involved confidential.

RECOMMENDATIONS

Lawyers are excellent at reviewing contract terms and conditions, as well as matters over data-protection, licence and ownership. However an experienced Project Manager or Project Assurance can be a useful resource, even if only for a few hours to review the contract, budget and project initiation document and make observations and recommendations.

Moreover a Project Assurance can also provide a useful independent and impartial review at any point during the project to help both parties get back on track.

Finally, mediation can be a good method to resolve issues and improve relations. Mediation is not a sign of failure, it is a sign of the commitment to work together and achieve a great outcome. Mediation promotes listening and understanding. It encourages a mutual solution focus, and therefore repairs and rebuilds collaboration, communication and trust and will deliver better outcomes.

WHAT IS PROJECT ASSURANCE?

Project Assurance is the process of critically assessing the health and viability of a project (at the risk of over-simplifying it, think of it as an audit function). 

Quality assurance in project management is a process of verifying quality standards through inspection to ensure that the outcome meets standardization and quality requirements for a product or a service.

The two are often best combined and provided externally and independently to offer objective and impartial assessment for the benefit of client / customer and vendor / supplier.

The Association for Project Management (APM)’s identify ten areas in a project organisation which assurance can increase the likelihood of success:

1. Client and scope
2. Risks and opportunities
3. Planning and scheduling
4. Organisational capability and culture
5. Supply chain
6. Solution
7. Finance
8. Social responsibility and sustainability
9. Performance
10. Governance

There may be10 areas, but each may be viewed differently according to one of these three perspectives: 

Business assurance…
measures project performance against its projected benefits to the organization. Is it an effective use of the company’s resources, for both finances and manpower?

User assurance…
considers the intended recipients of the project outcome, be it a product or service, and if they are being met.

Specialist assurance…
measures how suitable the delivered solution is for software and technical requirements.

Project Assurance can offer a view on process and product, outputs and outcomes and ostensibly as a coach guiding the conversation, rather than client or vendor making decisions it can facilitate a better communication, coordination, and collaboration in design, documentation and delivery of products and projects.

WHAT IS MEDIATION?

Business Mediation is an effective method for conflict resolution. It is successful between around 80% of the time. Parties discuss their disputes facilitated by an impartial third person(s) who supports them reaching a mutually agreed outcome. 

It can be better than alternatives including court litigation, arbitration or ombudsman decision because is inherently less adversarial, less expensive, and less stressful and confidential allowing for a flexible process which may help to preserve relationships. 

People are far more likely to stick to an agreement reached in mediation because people place a high value and greater ownership in outcomes they shared in creating

ABOUT THE AUTHOR

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 Tim@AdaptConsultingCompany.com 

FOLLOW *ADAPT CONSULTING COMPANY* https://www.linkedin.com/company/adapt-consulting-company

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.

Table of Contents

INTRODUCTION
KEY DOCUMENTS IN A PROJECT RESCUE
HOW DID WE GET HERE?
LESSONS LEARNED
PREDICTABLE FAILURE
WHAT NEXT?
CONCLUSION
ADAPT CONSULTING COMPANY

INTRODUCTION

As a project and change manager I do get asked to perform project rescues. Generally this is about 75% into the delivery phase when the sponsor starts to realise that they are paying for a lot of activity but not much is being delivered complete and OK. Moreover the strategy of more people, more time and more money seems to be making the situation worse.

KEY DOCUMENTS IN A PROJECT RESCUE

If invited to review, report and recommend I will generally look at the following documents rather like a doctor might look at the patient notes at the end of the bed.

PID – A Project Initiation Document [PID] contains the project description, document information, scope and exclusions, purpose, project objectives, interfaces, project deliverables, and assumptions.

CONTRACT – The contract is useful to compare to the PID and sadly in many cases the two do not align such that the expectations in the former are not obligations according to the latter.

As a professional mediator I see this a lot and am often asked to help both parties come to a workable solution that delivers the project rather than profit the lawyers.

DELIVERABLES – This may be part of the PID, Contract or Both, but ideally there should be a document that clearly states what will be delivered, the success criteria and acceptance process. For example not something vague like a “car” but a specific make, model, colour, specification.

BUDGET – I m always interested in where the money went and reconciling this to the expectations (PID) and agreement (Contract) and Ideally understanding the outcomes, outputs and deliverables.

Using all the above we have all the elements necessary to make an objective appraisal of [1] Where we are now; [2] where we wanted to be; and [3] How far we’ve got, and remain to go. We can the have a discussion about what we do, ditch, delegate, delay, de-scope in order to get back on track.

HOW DID WE GET HERE?

What remains is ostensibly the Lessons Learned, usually structured interview with key stakeholders and participates [responsible, accountable, consulted, and informed] to understand the people, process, policies, politics, performance and progress that got the project to the point where a rescue is necessary.

The Lessons Learned may be simple as …

What went well and we should continue – usually weekly meetings.

What went less well and we should stop or change – usually constant changes, scope-creep and delay.

What was missing and needs to be introduced – usually more consultation and linking payment to success

There can be much more here, for example reference to quality or compliance standards like GDPR, ITIL, ISO27001 etc., which I would be happy to expand upon in a conversation about quality and performance standards, success criteria and acceptance process.

I can offer a variety of templates and guides with varying levels of detail and diagnosis for anyone interested.

LESSONS LEARNED

Typically the Lessons Learned Report, from previous projects or previous stages is a useful resource

Lack Of Preparation
Example: Skipping or rushing a formal project kickoff meeting with all involved can lead to you being ill-prepared for project tasks or goals.

Inadequate Documentation And Tracking
Example: There isn’t a way to measure project success when important documents are not kept or are not easy to locate.

Poor Leadership
Example: Poor leadership can develop when leaders are not fully engaged because they have too much on their plate.

Failure To Define Parameters And Enforce Them
Example: Project scope creep resulting from project requirements can change planned deliverables as work progresses.

Inexperienced Project Managers
Example: Organizational structures to support good project management and the people who perform it simply do not exist in many companies. Plus, some companies lack a formal project management methodology.

Inaccurate Cost Estimates
Example: There is often a challenge with costing work on a project that has not been done before or is outside the normal type of work created.

Poor Communication Across Teams
Example: Teams are not aligned on project goals because they don’t know how or when to communicate updates.

Culture And Ethics At Odds
Example: Mismatched work ethics, geographic time zone issues, and language barriers can cloud the common goal and affect outcomes.

Poor Resource Planning
Example: Project failure can occur when there are limited resources or there is an inability to get the resources in place to get the job done due to budget and time constraints.

Disregarding Warning Signs
Example: Project Boards o Project Assurance meetings acknowledge the risks but do not make decision or take actions to change the circumstances that give rise to them.

PREDICTABLE FAILURE

Whilst many firms spend ages writing risk tables and reports, the common reasons for project failure can be quickly googled and addressed by simply thinking ‘What usually goes wrong’ and making sure there is provision for this in the agreements and plans up-front rather than a risk report which is about as useful as a black-box flight recorder in preventing project failures.

Indeed, instead of looking at possible risks and guessing the consequences it may be more helpful to look at common failures and see what we can do to avoid them. Effectively reverse engineering risk management

1. Poor planning
2. Inconsistently defined resources
3. Unclear objectives
4. Lack of detail control
5. Lack of transparency
6. Lack of communication
7. Change of direction
8. Unrealistic expectations
9. Lack of monitoring
10. Unrealistic due dates
11. Poorly assigned roles

WHAT NEXT?

This, of course, varies with every project.

For one organisation they faced a $1m a month penalty clause for late delivery so the focus was on de-scoping as much as possible to meet the legal minimum by the absolute deadline. Everything else got pushed into Phase 2. We succeeded, but it was ruthless.

For another organisation they sought and received a refund and credit value for unnecessary and unreasonable costs from the vendor and agreed ‘new ways of working’ to better define, document, deliver as well as test, accept and pay for the work being done.

For another organisation they parked what they had. Stopped the project and had a fundamental rethink about what their business really needed, aided considerably by the lessons learned from this bad experience.


CONCLUSION

It is worth having the “Key Documents In A Project Rescue” and possibly an interesting exercise to anticipate what might go wrong and checking what provisions are their to accommodate or address this in these documents.



If you dont follow, please do. Come and join me on our shared journey exploring new ideas and opportunities @timhjrogers #timhjrogers

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.

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

ADAPT CONSULTING COMPANY

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 #being #change #coach #data #datasharing #dpia #facilitation #feeling #gdpr #governance #jersey #lean #mediation #mentor #philosophy #pmo #policies #prince2 #privacynotice #procedures #process #processimprovement #programmes #project #psychology #publicsector #purpose #scrum #sixsigma #technology #thinking #timhjrogers #training #waterfall #workflow #workshops