This document outlines a process for rescuing troubled software projects. It begins with investigating what went wrong through questioning project members and reviewing documentation. The goal is to uncover the root cause of issues rather than blame individuals. Common causes include unrealistic timelines, incomplete requirements, and poor communication. Once the root cause is determined, the project must be re-planned to address weaknesses while building team confidence. Early successes are important to demonstrate new controls are effective. Regular governance ensures past issues do not recur. A case study shows making difficult changes, re-planning thoroughly, and achieving quick wins saved a stalled pharmaceutical software project.

1. Rescuing and Reviving Troubled
Software Projects
Barry Curry
Director and Principal Consultant - Système

2. • 7 out of 10 software projects in the Pharmaceutical Industry fail to
meet expected targets and milestones or fail completely
• Types of failure range from missing milestones to exceeding budget
to the project being cancelled – effect on business is huge
• How do large software projects fail?
– Gradually at first, and then suddenly
• Why do software projects fail?
– The reasons are many
Facts About Projects

3. Project Problems and Solutions
We cannot predict every project issue - we can develop a process for
dealing with every problem
A vast majority of software projects are recoverable but major
changes in the team, process, strategy and plan may be required
This process for rescuing troubled projects will demonstrate how to
• Get to the bottom of the project issues
• Learn from the mistakes made
• Re-plan for success
• Put effective project governance in place
• Avoid a recurrence of the original project problems

4. Projects and People
• Each project has its own culture and pace
• These elements are unique to every project – even within a
programme of similar projects
• The Project Manager must make every effort to understand this – key
to this is understanding the people
• Project management is in essence people management intertwined
with fixed budget, scope and resources

5. • The solution that works for one project may not work for another – but
the process to identify the issues is consistent
• When rescuing a troubled project we need to understand the detail
• In the detail we will find the answers to what went wrong
• The details must be reviewed with an open mind and we must de-
personalize any findings or corrective action
Project Investigations

6. • Before you embark on a Project Rescue mission, consider this…..
• Rescuing any project will require commitment, effort and some
difficult conversations but honesty and transparency are key to
success
• Are you willing to get your hands dirty to save the project from
failure?
Commitment to Action

7. Four stages of Project Rescue
• Investigation - questions, interviews and data gathering
• Root Cause - What went wrong? How and Why?
• Key learnings and re-planning
• Kick off and run the project
The Process

8. • As with all investigations, we commence with questions
• We ask a series of questions in order to retrieve the facts
• We leave all opinions at the door until we are satisfied that we have all
the data we need to proceed to the next stage
Let’s Begin with Questions

9. Here’s some advice from history
“Everything we hear is an opinion,
not a fact.
Everything we see is a perspective,
not the truth.”
Marcus Aurelius
Roman Emperor and Philosopher
(Now Deceased)
Warning – when gathering information……

10. • Why are we here to investigate a project problem?
• What evidence is available to help build an accurate picture of the issue?
• Is there any obvious chain of events or lack of action that may have
caused the issue?
• What milestones have been missed?
• What are the overall project metrics telling you?
High Level Questions

11. The most important questions…………………
How do you know that there is a problem with the project?
How was it first recognized that there is a problem with the project?
What are the key metrics that indicate there is a problem?
Important Questions

12. • Based on the original plan – where did you expect the project to be
at this stage?
• What is the one big factor that tells you that the project is not on
track?
• What investigations or diagnostics have taken place so far?
More Questions

13. • Is the Project Manager overwhelmed?
• Is the Project Manager still in place?
• Is the Project Manager under obvious pressure?
• Did the Project Manager call for help?
• Was support provided?
• How has the crisis been managed so far?
Project Management

14. Teamwork
• What is the feedback on teamwork?
• How are the team working together?
• Has the team already been changed to get the project back
on track?
• Any negative influences affecting the team?

15. Phases of a project
Assess each phase for performance
• Specification
• Design
• Build
• Test / Qualify
• Operation
Analyze Each Phase

16. Once the facts have been gathered
• Assess the evidence
• Uncover the root cause
• This is the best opportunity to learn and improve performance
• Learn from the problems encountered to avoid a recurrence
Facts

17. Problem Statement– Unable to Start Software Build Phase
Why?
The design documents are not approved
Why?
The design details are not complete
Why?
The user requirements are not approved
Why?
The users are unclear on what they need
Why?
The business analysts weren’t clear on the best proposed solution
Why?
The business requirements workshop was poorly planned and executed
Why?
There was insufficient time allocated to the workshop
Why?
There was pressure on to kick off the project……….
Root Cause
Example
Suddenly the Project Manager
announces that there is a
problem…...

18. When you reach a point where you can’t get any
further with the “Why?”, then you know that you have
found the underlying issue or it is very close.
Root Cause

19. • Customer expectations were not managed
• Inadequate governance around the key milestones in the schedule
• Poor communication
• Dependencies and enablers not well communicated and not
understood
• No accountability
Root Cause Example - Analysis

20. Root Cause Example - Analysis
What should have happened?
Project Manager should have
• Met with the project sponsors
• Called for more time to complete the requirements
• Flagged missed milestones to the stakeholders
• Made project team members accountable
• Not proceeded to the design phase in the absence of complete
requirements

21. For each missed milestone or project issue
Either
Something Unexpected Happened
Or
Something that was expected to happen did not happen
Review Each Missed Milestone

22. • In what area is the problem most prominent?
• Cost
• Schedule
• Scope Control
• Milestones Passed without Completion of Scope
• Resources / Management
• Reporting
• Project Sponsorship
• Governance
Project Problems

23. • A question to be asked at this stage is:
• Were there any previously unidentified unknowns that
surprised us?
• Design Changes
• Testing Problems
• Other influencing Factors
Unknowns

24. • Once the root cause is clear and the lessons have been learned we
can re-plan with confidence.
• Digging into every detail needed in order to produce the most
realistic plan possible.
• The plan may take a number of attempts to assemble – ensure the
original issues are addressed in the plan
• Put monitoring and controls in place to allow us to run the project
effectively – this should be part of the re-plan
Root Cause and Re-plan

25. • How does current knowledge compare with the original plan?
• Original plan missing any key activity?
• Enough knowledge available at the time to plan correctly?
• Was the project plan re baselined at any stage and if so why?
• Was there adequate risk assessment and risk management ?
• Did any risks become issues?
Project Plan Accuracy

26. • Current team capable of pulling together and supporting each other?
• Is this the right team?
• Any toxic team members?
• All the team members clear on roles and responsibilities?
• Are the project sponsors clear on their roles?
Teamwork

27. Decision Time for the stakeholders
Now that the truth has been exposed, are you still willing
to get your hands dirty to save the project?
Are you ready make some big changes?
Question for Stakeholders

28. Do nothing – continue with the current set up and strategy and
see if the project performance improves
OR
Stop - make changes to the all major elements of the project
depending on the source of the issue and the magnitude of the
problem
Then you can re-plan for success
Stakeholder Options
Subtle Reminder:
Doing Nothing about a problem is a conscious
decision not to take action – this does not
exonerate the stakeholders from responsibility
and accountability just because they decided
to “Do Nothing”

29. Vital Lesson:
If you require a different output then you need to:
Do things differently
Do different things
The project constituents must be changed
This includes the budget.
Re-planning

30. Workshop with the correct SMEs and Resources
• Deep dive into each deliverable, milestone and pre-requisite
tasks
• Walk through each task and its dependencies
• Duration
• Pre-Requisites
• Dependencies
• Resource
• Risk
• Cost
Re-planning

31. • The new plan must show early progress
• Plan the tasks so that delivery of at least one major milestone
follows quickly
• At the project kick off demonstrate the learnings from the previous
project difficulties
• Display the confidence to achieve your goals
• Maintain the momentum
Kick Off

32. Demonstrating success early is important because:
• Stakeholders will have confidence in the new plan
• The project team will gain confidence in their ability to deliver
• You can demonstrate control to all concerned
• When a milestone is reached – congratulate and communicate
Demonstrate Early Success

33. Project Tracking and Status updates need to focus on areas of
previous weakness to ensure the previous issues are not repeated.
• This should be a specific metric when reviewing project
performance
• Act swiftly and effectively on any concerns
• Manage the communication about the project progress
• Ensure everyone concerned is updated regularly
Governance

34. • New Pharma Plant € 110 million Investment
• Manufacturing software systems project stalled – no progress
• Ultimatum issued from Corporate HQ
• 3 Months get back on track and achieve first major milestone
• This process was applied
• Hard decisions were made
• The team was changed, the project was re-planned and restarted
• Within 3 months – the target was achieved
• Within 2 years – FDA approval and in commercial production
Case Study

35. • Equipment had not been tested effectively with the software
• Known issues were brushed under the carpet
• Unfinished work was being reported back as complete
• Team work was non existent
• Communication was very poor
• Governance was ineffective – focussing on a report rather than progress
• Company culture did not encourage transparency
• Test records were falsified
• Design was incomplete
Case Study - Details

36. Summary – To Ensure Success
• Everyone must understand what went wrong, how it went wrong
and why it occurred
• Hard decisions will need to be made – changes to the team and
approach
• The reason for failure must be monitored in the re-planned project
• Respond swiftly and effectively to potential issues
• Orchestrate and ensure early success in the re-planned project

37. Thank you for your
attention
Any Questions?
Time to Hit the
Road

38. mail: barry@systeme.ie
web: systeme.ie
Twitter: @projectsdoctor
Contact

39. 2018 Sponsors
www.pmsummit.global17th July 2018 Dublin, Ireland