Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rescuing and Reviving Troubled Software Projects


Published on

This presentation guides the audience through a well proven process for rescuing and reviving troubled software projects and is based on over 20 years of experience in industry. From investigation to re-planning, kick off and running the project, tools and techniques for project rescue are described that can be applied to all types of software projects. This practical and effective approach provides a unique insight into what is required to rescue a project and get that project back on track.

Published in: Software
  • Login to see the comments

Rescuing and Reviving Troubled Software Projects

  1. 1. Rescuing and Reviving Troubled Software Projects Barry Curry Director and Principal Consultant - Système
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Phases of a project Assess each phase for performance • Specification • Design • Build • Test / Qualify • Operation Analyze Each Phase
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 37. Thank you for your attention Any Questions? Time to Hit the Road
  38. 38. mail: web: Twitter: @projectsdoctor Contact
  39. 39. 2018 Sponsors www.pmsummit.global17th July 2018 Dublin, Ireland