Readjusting Project Dynamics for a Successful Outcome Dan Williams Director, Project Consulting April 2012

2 Averting Disaster We’ve all been involved with a project that was in trouble. How do you fix it? Where do you start? How do you avoid disaster?

3 Why you Should Care We should be involved in QA, not just testing We are sometimes the only advocate for the customer We need to recognize that QA is integral to the larger project ecosystem We must be solution oriented not focused on the problem Having a “global” view will enhance your career path

4 The Project The project was implementing a new enterprise management tool integrated with several third party vendors and customized to meet our specific business needs. The PM lost stakeholder support and confidence; placing the project in danger Issues were many, including:

5 Issues Incomplete and missing requirements  Assumptions rather than facts  Incomplete notes from meetings  No follow-up with stakeholders  Requirements gathering excluded entire groups  Incorrect, incomplete and unclear data mapping  Lack of information architecture Requirements based on incorrect premises  What do you want, not what do you need  Copy of what was already in place  Effort not boxed

6 Issues Part 2 No Formal Test Plan  Migration testing: spot checking by PM and one developer  Integration testing (smoke test at cutover)  Third-party functionality – spot checking by stakeholders  Functionality testing – developers, self-directed UAT  Pick up the pieces after conversion No vendor coordination Project behind schedule Negative earned value Documentation and training duties assigned  Unclear expectations  Poor knowledge transfer Reporting was an afterthought

7 Issues Part 3 Project manager  Didn’t listen  Talked over people  Ignored stakeholder concerns  Antagonistic relationship with coworkers  Insulated team from stakeholders, SMEs, and vendors –Little to no interaction –All project knowledge centered in PM  Development team didn’t understand priorities  Stakeholders didn’t have good feel for project status  Fragmented team – portion of team working on unproductive tasks

8 What Determines Whether a Project will be Successful? What do you think of your team’s execution? “I’m in favor of it!” John Mckay Tampa Bay Bucs Coach 1976

9 Project Success / Challenge Factors Project Success % of Factors Responses User Involvement15.9% Executive Management 13.9% Support Clear Statement of 13.0% Requirements Proper Planning9.6% Realistic Expectations8.2% Smaller Project Milestones7.7% Competent Staff7.2% Ownership5.3% Clear Vision & Objectives2.9% Hard-Working, 2.4% Focused Staff Project Challenge % of Factors Responses Lack of User Input12.8% Incomplete Requirements12.3% & Specifications Changing Requirements11.8% & Specifications Lack of Executive Support7.5% Technology Incompetence 7.0% Lack of Resources6.4% Unrealistic Expectations5.9% Unclear Objectives 5.3% Unrealistic Time Frames 4.3% New Technology3.7% Chaos Report – Standish Group

10 Project Success / Challenge Factors Project Success % of Factors Responses User Involvement15.9% Executive Management 13.9% Support Clear Statement of 13.0% Requirements Proper Planning9.6% Realistic Expectations8.2% Smaller Project Milestones7.7% Competent Staff7.2% Ownership5.3% Clear Vision & Objectives2.9% Hard-Working, 2.4% Focused Staff Project Challenge % of Factors Responses Lack of User Input12.8% Incomplete Requirements12.3% & Specifications Changing Requirements11.8% & Specifications Lack of Executive Support7.5% Technology Incompetence 7.0% Lack of Resources6.4% Unrealistic Expectations5.9% Unclear Objectives 5.3% Unrealistic Time Frames 4.3% New Technology3.7% Chaos Report – Standish Group

11 Open the lines of Communication Engage the stakeholders  Make them part of the team  Develop project excitement Clearly communicate project news  Newsletter  Updated schedule  Generate support and excitement Be open and realistic about project status

12 Baseline the Project Assess current progress and risks Identify known gaps Identify areas needing further investigation Prioritize areas and tasks

13 Divide and Conquer Assign area owners with clear, measurable objectives Collaborate Coordinate Report Follow-through

14 Go Back to the Beginning Gather/Reaffirm/Clarify requirements Rebuild trust with Stakeholders  Keep meetings focused and effective  They need to know their time and opinions matter  They need to know they are heard  They must know you care  Point out the results of their input Replace faces where necessary

15 Triage and Scheduling Triage  Evaluate critical path and overall timeline  Evaluate dependencies – especially external  Label items for sign-off, hot-fix, and future  Push out or eliminate unnecessary items Adjust schedule if necessary  Communicate schedule issues immediately  Do it once, do it right

16 Get to Work Prepare the team for tough work Plan for a regular schedule but be ready to do what is necessary 80/20 rule  Focus efforts on key areas that provide the most value  Deal with the rest as time permits Involve users in testing and acceptance Recognize time criticality of efforts  What is required for signoff  What can be done after code freeze  What can be a hot fix

17 Win Them Over with Support Be there Be knowledgeable Be responsive Be good

18 Allow for Future Phases Deal with cut/delayed functionality Align with proper requirements Adjust for stakeholder/user misrepresentation of needs Bug fixes

19 Project Recovery Summary Open lines of communication Assess Risks Prioritize Divide and conquer Rebuild trust Go back to the beginning (requirements) Triage Cut/push out non-essential areas Adjust schedule if necessary 80/20 rule Schedule work according to priority Work, work, work Be prepared with strong support and resolve issues quickly Allow for additional phases

20 Questions

21 Contact Information Dan Williams Director of Project Consulting Main Cell