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