Overcoming & Managing Project Challenges Workshop

Leading projects can be tough, particularly in the face of change. But, no matter what you do, you’ll likely encounter some kind of change on any given project. And whether that change is related to people, process, scope, timeline, or budget, you have to sort through it quickly and gracefully to keep your project moving in the right direction.
In this workshop with Brett Harned, we’ll explore typical project red flags and discuss the facets of project change, as well as solutions to make it easier to adapt and lead projects to success.

This workshop is relatable to anyone looking to pick up skills on being a better team leader, team member, employee, and human. Whether you're a designer, developer, PM, or manager, Brett will help you discover new ways to address project issues before they become problems.

Transcript

1. DIGITAL PM WORKSHOP: OVERCOMING & MANAGING
 PROJECT CHALLENGES JANUARY 8, 2018
 TRIANGLE UXPA PRESENTED BY BRETT HARNED
 brett@brettharned.com | @brettharned

2. brettharned.com
 brett@brettharned.com
 @brettharned Digital PM Consultant & Coach digitalpmsummit.com
 @digitalPMsummit Hi, I’m Brett Project Management
 for Humans
3. WHY IT’S IMPORTANT TO TALK ABOUT CHANGE • We all experience project change • We all experience organizational change • Sometimes it’s about setting and managing expectations • Sometimes it’s about scope (and scope creep) • It’s often out of our control • We all handle change differently
4. Let’s take this opportunity to learn from one another!
5. AGENDA 9:00-9:30 9:30-10:30 
 10:30-12:00 12:00-1:00 1:00-2:00 2:00-2:30 2:30-3:00 Introductions and Ice Breaker
 Handling Red Flags in Project Docs Exercise Ch-ch-changes! Exercise & Discussion Lunch Facing Project Challenges Discussion Wrap Up & Round Table Exercise Q&A

6. TODAY IS ABOUT: LEARNING SHARING PARTICIPATING DEBATING
7. LET’S GET STARTED!
8. DO YOU WORK WITH THE FOLKS AT YOUR TABLE? BUT FIRST:
9. “ONE THING” EXERCISE
10. INNTRODUCE YOURSELF: What’s your one thing? What types of projects do you work on? Name and Company, City What types of contracts do you manage? (fixed fee, T&M, retainer, none?)
11. WHAT’S YOUR ONE THING?
12. EMPLOY THE “ONE THING” EXERCISE • Useful with stakeholders and teams to collect feedback and find key themes • Helps with understanding priorities • Helps to build project requirements (or requests) • A fun way to get ideas out
13. HANDLING RED FLAGS IN PROJECT DOCS
14. DISCLAIMER • We’re NOT providing legal advice here, in fact, you should get all contracts reviewed by a lawyer before sending/ signing • Red flags and solutions identified and discussed in this session are related specifically to project management — and issues you encounter due to the way a scope is written. • Think about these red flags in terms of issues or risks that they might impose on your projects
15. THE PURPOSE OF A PROJECT SCOPE • Define a legal business relationship • Set expectations around what will be done, and possibly what will not be done • Outlines a budget for the task (or tasks) at hand • Outlines a timeframe for the work • Defines responsibilities of each party, and how you will contribute to the success of the project
16. “A contract should be specific and buttoned down tighter than Joan Rivers’ face.” - Dan Rather
17. A STRONG CONTRACT: • Provides an overview of who is hiring who • Clearly states the goal of the project/type of project • Clearly states the roles and responsibilities of each party • Defines terms that may not be used by all parties • Lists deliverables to be created and reviewed • Specifies date, time, and place of performance • Describes warnings or actions to be taken if things go off track (what happens if a someone changes their mind?) • Identifies a cost associated with all work contained in project • Include all the legalese your lawyers will require
18. WHAT IS A CONTRACT
 RED FLAG? • A warning sign that something might go wrong • In contracts, a red flag might show up with: • Vague language • Undefined terms • Open-ended definition of scope • Unresolved terms around revisions/approvals • Unclear ownership • Poorly defined terms of liability • Poorly weighted/defined billing terms
19. WHO IS 
 RESPONSIBLE FOR WRITING 
 CONTRACTS?
20. WHAT ARE TYPICAL RED FLAGS YOU FIND
 IN CONTRACTS?
21. RED FLAGS EXERCISE
22. HOW THE EXERCISE WILL WORK: • I will present a contract clause on screen • Individually, you will determine the red flags (feel free to make notes using the paper/pens provided) • As a group, you will: • Discuss the terms • Discuss your red flags • Discuss how you’d address the red flag on an active project • Then we’ll discuss as a larger group
23. EXAMPLE 1: Deliverables Discovery Our goal with discovery is to understand your business, its stakeholders, users, and your goals for each. In order to do this, we might employ a few activities to gain a better understanding of the needs and goals for the redesign:
 •Stakeholder Interviews •User Interviews •Competitive Analysis •Heuristic Analysis •Team Workshop Sessions •Document Reviews •Design Prototyping Exercises
24. What are the red flags?
25. Discovery Our goal with discovery is to understand your business, its stakeholders, users, and your goals for each. In order to do this, we might employ a few activities to gain a better understanding of the needs and goals for the redesign:
 •Stakeholder Interviews •User Interviews •Competitive Analysis •Heuristic Analysis •Team Workshop Sessions •Document Reviews •Design Prototyping Exercises EXAMPLE 1: Deliverables
26. WHEN IT COMES TO DESCRIBING DELIVERABLES: • Be sure to be very clear about what you will and will not do. • Use finite terms, avoid words like “might,” “possible,” etc. • Make sure there is an estimate that correlates to each activity so you can avoid scope creep
27. WHEN IT COMES TO FUZZY SCOPE DEFINITION: • Review scope early; set expectations on activities • Determine what is needed for the project to meet its goals and discuss openly • Be prepared to defend your decisions with examples of best practices and discussion • Confirm activities in writing with team and stakeholders (in a brief, a plan, and status updates)
28. Design We will create designs for the look-and-feel, layout and functionality of your web site. This contract includes one main design plus revisions. After you’ve approved the design, we will design the remainder of the site for your review. EXAMPLE 2: Deliverables & Feedback
29. What are the red flags?
30. Design We will create designs for the look-and-feel, layout and functionality of your web site. This contract includes one main design plus revisions. After you’ve approved the design, we will design the remainder of the site for your review. EXAMPLE 2: Deliverables & Feedback
31. DESCRIBING DELIVERABLES & PROCESS: • Explain how a deliverable will be created and presented (PhotoShop comps, InVision, live pages, etc.) • Quantify what will be delivered (one concept? one page?) • Clearly define your revision plan, how feedback is accepted, how long it should take, and when and how an approval is accepted • Explain what happens after the approval (next steps)
32. DEALING WITH UNCLEAR DELIVERABLES AND PROCESS: • Review scope early; set expectations on activities • Work with your team to figure out what is doable within your budget • Spell out the steps of your process in your plan • Add notes to your plan to clarify scope • Set stakeholder expectations prior to the meeting by explaining what will be presented • Manage expectations by reiterating what will be shown right before presenting • Discuss next steps and your revision plan after presenting
33. XHTML/CSS layout templates If the project includes XHTML or HTML markup and CSS templates, we will develop these using valid XHTML 1.0 Strict markup and CSS2.1 + 3 for styling. We will test all our markup and CSS in current versions of all major browsers. EXAMPLE 3: Technology
34. What are the red flags?
35. XHTML/CSS layout templates If the project includes XHTML or HTML markup and CSS templates, we will develop these using valid XHTML 1.0 Strict markup and CSS2.1 + 3 for styling. We will test all our markup and CSS in current versions of all major browsers. EXAMPLE 3: Technology
36. DESCRIBING TECHNOLOGY: • Understand general tech needs prior to scoping • Remember that not everyone speaks tech! • Define terminology when possible/applicable • Create a list of browsers to be tested; be clear about your plan and what is in/out of scope
37. DEALING WITH TECHNOLOGY & SCOPE: • Use the opportunity to engage and educate clients who are not tech savvy • Discuss technology needs at kickoff and plan accordingly • Document all needs and share notes publicly, or in a project brief—get agreement • Define a list of browsers you will test on
38. Timeline Based on what we know, this project will take 6 months to launch. An overall timeline is below: October 31 - Kickoff November - Discovery December - UX Design January- Graphic Design February-March - Code April - QA& Launch EXAMPLE 4: Timeline
39. What are the red flags?
40. Timeline Based on what we know, this project will take 6 months to launch. An overall timeline is below: October 31 - Kickoff November - Discovery December - UX Design January- Graphic Design February-March - Code April - QA& Launch EXAMPLE 1: Timeline
41. DESCRIBING TIMELINES: • Be wary of committing to specific timelines in contracts; try ranges • Define activities that can delay your plan • Define client/stakeholder responsibility and how it can impact the plan • Define start dates • Make a detailed project plan an early deliverable • Be sure to note that it will need to be approved
42. DEALING WITH IMPOSSIBLE TIMELINES: • Understand the motivation behind the deadline • Create a realistic plan given the scope and activities needed to complete the project successfully • Discuss with your team: what can be cut to meet a tighter deadline? • Discuss with your stakeholders: are you comfortable cutting activities to meet the deadline within the current scope? • Revise and review the plan; commit to changes • Share the plan far and wide, and keep it updated • Communicate next steps, action items, and risks weekly
43. Warranty Upon launch of the website, <Company Name> certifies that it will deliver a bug-free experience. If issues do arise after launch, <Company Name> will be available to make updates as needed. If <Client Name> would like to extend its relationship beyond the two weeks of bug fixing and support, <Company Name> will charge for services at an hourly rate of $175. EXAMPLE 5: Warranties
44. What are the red flags?
45. Warranty Upon launch of the website, <Company Name> certifies that it will deliver a bug-free experience. If issues do arise after launch, <Company Name> will be available to make updates as needed. If <Client Name> would like to extend its relationship beyond the two weeks of bug fixing and support, <Company Name> will charge for services at an hourly rate of $175. EXAMPLE 5: Warranties
46. DESCRIBING WARRANTIES: • Be wary of “certifying” anything • Don’t commit to launching with zero bugs • Define how bugs will be identified and tracked in a shared system • Define a plan and how clients will participate in QA • Set an end date or milestone for your project; additional work should be done under separate scope
47. DEALING WITH QA & WARRANTIES: • Explain that websites are living and changing; the minute a client touches it, it has changed (and can create new bugs) • Make QA a part of your project plan; define start and end dates for QA • Involve your clients; use one big tracking system • Prioritize tickets: launch, post-launch, phase 2 • Provide regular updates on progress in QA/bug fixing
48. BEST PRACTICES FOR CONTRACTS • Do not start work until you have one signed • Spell out deliverables and non-deliverables • Spell out ownership • Set up reasonable payment and terms • Be clear and honest about the budget • Always talk through it when you kick off a project
49. QUESTIONS?
50. CH-CH-CHANGES
51. Change management is the process, tools and techniques to manage the people side of change to achieve the required business outcome.
52. WHAT CAUSES CHANGE? • Stakeholder changes their mind • Business changes/shifts goals • Organizational staff change • Poorly defined requirements • Changing technology • Change in timeline • Resourcing issues • Disagreement • Bugs or defects
53. HOW DO WE HANDLE CHANGE? • We assess it and understand the change • We question the change • We brainstorm alternatives • We identify its related issues and impacts on the project • We estimate the impacts on time and budget • We address the change and issue documentation • We roll it out and move on
54. DO YOU HAVE ANY TOOLS OR PROCESSES IN PLACE TO ADDRESS CHANGE?
55. Understand. Communicate. Manage. Facilitate.
56. UNDERSTAND: 
 WRANGLE DOCUMENTS • Scope • Strategy/Creative Brief • Requirements • Project Plan • Status Reports • Deliverables
57. 
 IS THIS A SCOPE PROBLEM OR AN EXPECTATIONS PROBLEM?)
58. EXPECTATIONS SHOULD BE SET &
 BASED ON A SCOPE
59. COMMUNICATION TIPS • Talk about scope early to make sure everyone is aligned • Reiterate next steps, goals, and scope of deliverables on check-in calls prior to deliverables • Make sure to talk about the scope of the deliverable/ project at the beginning of a presentation
60. Let me confer with the team and get back to you with next steps.
61. Let me see what we can do within our scope and get back to you with next steps.
62. We can’t do that, but 
 we can…
63. SOMETIMES YOU HAVE TO SCOPE OR RE-SCOPE
64. ESTIMATES ARE NEVER EXACT
65. estimate noun noun: estimate; plural noun: estimates ˈɛstɪmət/ 1 1. an approximate calculation or judgement of the value, number, quantity, or extent of something.
66. CHANGE IN PLANS? NEED TO DO MORE WORK? 
 ARTICULATE EFFORT: • Dissect the issue/additional work • Discuss goals • Determine impacts • Budget • Timeline • Estimate the work • Show your estimates, be transparent
67. A Work Breakdown Structure (WBS) is a method by which you can visually represent the composition of a project by breaking down all project stages and aspects into their smallest possible components.
68. WORK BREAKDOWN STRUCTURE
69. WORK BREAKDOWN STRUCTURE: 
 WIREFRAMES BRAINSTORM Internal Meeting - half day Personal Brainstorming - 1 day DESIGN
 Create Wireframes - 6 days Internal Team Review - half day Internal Iteration - 3.5 days
 PRESENT Prep presentation - 1 day Review with Client - 1 day Collect Feedback (x3) - 3 days Iterate (x2) - 10 days Total Time: 2 days Total Time: 10 days Total Time: 15 days
70. BREAK EVERYTHING DOWN IN TO SUB TASKS
71. OTHER ITEMS TO DISCUSS If scope changes, these things may change too: • Timeline • Requirements • Budget • Resource availability • Quality of work
72. SEEMS EASY, RIGHT? If you get stuck: • Don’t be afraid to ask questions • Ask colleagues for opinions • Check project histories (if you have them) • Remember, estimates are not exact
73. Remember: Understand. Communicate. Manage. Facilitate.
74. DEFINE CHANGE EXERCISE
75. HOW THE EXERCISE WILL WORK: • I will present a scenario on screen • As a group, you will: • Discuss the change and team/expertise involved • List questions you’d ask • Estimate the level of effort for the change • Determine if you’d issue a Change Request • Then we’ll discuss as a larger group
76. A new stakeholder takes over your project right before you kick off development. She needs to be on-boarded to the project to understand stated goals, history, decisions, and current plans. THE CHANGE: YOU WILL: ASSUMPTIONS: • Previous stakeholder contact has left • Research, UX, and design are approved; changes to decisions will impact your scope • All scope docs and deliverables are in Basecamp • Currently the project is under budget by 5% and on time 1.List the questions you will ask in follow-up to the request 2.Discuss who from your team should be consulted on the change 3.Determine if a change request should be issued 4.Determine the level of effort required (in hours/ days/weeks) to address the change
77. WHO WANTS TO SHARE?
78. You’ve delivered final designs after 3 rounds of stakeholder feedback and find out that a senior executive—who has not yet been involved in the project—wants to review the designs with you in person next week. THE CHANGE: YOU WILL: ASSUMPTIONS: • Stakeholders involved and review dates were determined and agreed to early in the project and confirmed with a project plan • You do not have the budget left to conduct an additional meeting • This will cause a delay in timeline, and you might even lose dev resources • Under contract, you bill for any travel time and expenses 1.List the questions you will ask in follow-up to the request 2.Discuss who from your team should be consulted on the change 3.Determine if a change request should be issued 4.Determine the level of effort required (in hours/ days/weeks) to address the change
79. WHO WANTS TO SHARE?
80. You just launched a website yesterday after 9 months of working on it, and your client reveals that they’ve been working on a new logo that is now complete. They need you to replace every instance of the logo on the site with the new one ASAP. THE CHANGE: YOU WILL: ASSUMPTIONS: • You had no idea about this logo project • It’s a minor update to the old logo, so it doesn’t require any additional design work • You’re currently in a 2-week bug fixing warranty phase, so your team is working on the project • You have exhausted your project budget 1.List the questions you will ask in follow-up to the request 2.Discuss who from your team should be consulted on the change 3.Determine if a change request should be issued 4.Determine the level of effort required (in hours/ days/weeks) to address the change
81. WHO WANTS TO SHARE?
82. Your client is responsible for writing, editing, and entering new content into the CMS. This work is supposed to be complete today, but they told you that they need 3 more weeks to get it done. THE CHANGE: YOU WILL: 1.List the questions you will ask in follow-up to the request 2.Discuss who from your team should be consulted on the change 3.Determine if a change request should be issued 4.Determine the level of effort required (in hours/ days/weeks) to address the change ASSUMPTIONS: • You were planning to launch on Friday, and your team is scheduled to move on to a new project • Your project is 10% under budget • The project has been pretty good up until this news came in • You might have some copywriters available to help
83. WHO WANTS TO SHARE?
84. BE THE SCOPE COP
85. ALWAYS IS HAPPENING ON YOUR PROJECTS KNOW WHAT & AVOID SURPRISES
86. QUESTIONS?
87. LUNCH
88. PROJECT SCENARIOS
 DISCUSSION & PRESENTATION
89. BROKEN PROCESS: As a team, you’re committed to trying some Agile methods on client projects. Your clients have agreed to participating in sprint planning and demos, which sounds great. Things were going well until you demoed your first sprint and: • only two of four stakeholders showed up • they were confused by what they were seeing—they expected to see full working pages, and you delivered pieces of functionality (as planned) • they are uncomfortable moving forward without seeing a home page design
 You want to continue work, but you’re nervous. What should you do?
90. DEFINE “PROCESS” • Educate your clients on process • Present a plan and describe activities at a high level, and on a granular level • If using “Agile,” explain the importance of ceremonies; If using more traditional approaches, explain the importance of milestones and dependencies • Be sure to get ALL meetings on calendars ASAP • Schedule status meetings to discuss process/progress • Check in on and discuss process periodically • Reiterate process points (what we did, what we are doing, and what is next) at all presentations
91. Projects require partnership.
92. DEFINE INVOLVEMENT • Ensure that clients and stakeholders understand their involvement—and what it means to the project timeline and budget • Set expectations about involvement/ commitments—and what can happen if they do not live up to expectations
93. IDENTIFY PROJECT STAKEHOLDERS • Project Owner/Core Team • Primary Stakeholders • Secondary Stakeholders • Management • Executive
94. GRAB THIS RESOURCE http://brettharned.com/blog/workshop-resources/
95. Figure out what is not working and fix it.
96. DISCUSS THE ISSUES • Conduct a brief, informal retrospective • Make changes based on what will be realistic: • New level of client involvement? Different team lead? • Different form/level of communication in stakeholder team? • More frequent checkins? • A discussion about priorities?
97. DISCUSS THE IMPACTS • Assess further impacts to timelines, budgets, staffing plans, schedules and clearly communicate the changes to everyone involved • Be very clear about your new plan: • Deliver an updated plan and present it • Write out a description of the change in plans • Write a change request to gain agreement
98. Don’t be afraid to change or experiment with process.
99. QUESTIONS?
100. NEVER-ENDING QA: You launched a site and everything went really well. You had 2 weeks of QA and bug fixing prior to launch, and were confident with what was delivered.
 Three weeks after launch, your client has made updates and added pages. But they need help, so they logged 15 new tickets in your ticketing system and are considering it a part of the current scope.
 Your project wrapped, so you’re out of scope. How should you handle this change?
101. “Fixing one bug created a new bug.”
102. IS IT A CHANGE? • Ensure that your contracts terms are clear as it relates to warranty and support after the project has been transitioned to clients. • Figure out what caused the issues • Determine if the items are on your team vs. the clients • Depending on scope, budget, timeline, and resourcing, you’ll have to make a call
103. Will rejecting this work—or ownership of it —affect your relationship?
104. Sometimes you have to eat the cost of change.
105. WHAT IS THE PRIORITY? • If you will approach the issue, discuss: • The priority of each issue • The size of each issue (estimating) • What levels of priority mean and what the associated deadlines are for each
106. DO THE RIGHT THING • Many people think PMs always take the easy way out • Involve people in the discussion and decision • Document conversations, decisions • If writing a CR and having that tough conversation is needed, do it
107. QUESTIONS?
108. UNEDUCATED CLIENTS: You reviewed your project plan with your client, and they agreed to the overall plan and tasks. Things were working really well until right after designs were approved. Your client asked, “Why is this taking so long? We need this done in 3 weeks.” Wrapping up in 3 weeks would be impossible. How should you address this issue?
109. You have to ask questions to understand motivations
 (and sometimes emotions)
110. I’m concerned about this sudden change in timing. Can I ask why we’re being asked to change our plans?
111. Is there a related project or business goal driving this change?
112. I’m happy to sit down and discuss our process and the associated effort required…
113. Wrapping up the current planned work in three weeks will be virtually impossible, but let’s discuss possible alternatives…
114. I’m sorry, we cannot move the timeline up, but…
115. Don’t be afraid to say “No.”
116. But lean toward saying, 
 “No, but…”
117. TEACHING CLIENTS= WIN-WIN
118. QUESTIONS?
119. SOURING RELATIONSHIP: You started a new project with a new client and things have been great. But something happened and you can’t figure it out. Your contact has missed three meetings and stopped responding to your calls, and you need to talk. This is going to force you to pause the project, and the client has a hard deadline. How should you approach this situation?
120. COMMUNICATE COMMUNICATE COMMUNICATE COMMUNICATE COMMUNICATE COMMUNICATE
121. Great business relationships are built on solid communications
122. But remember that we all communicate differently.
123. 4 TYPES OF COMMUNICATORS Analytical Intuitive Functional Personal
124. ANALYTICAL 
 COMMUNICATORS • Prefer facts and data • Prefer specific language, not vague • Like communication to be unemotional; logical and dispassionate
125. INTUITIVE 
 COMMUNICATORS • Thinks big picture • Wants to get to the point; not about details • Enjoys challenging convention • Can be frustrated by detailed conversations
126. FUNCTIONAL 
 COMMUNICATORS • Likes process, detail, timelines, well-thought out plans • Communicates in step-by-step fashion • Plays Devil’s Advocate • Likes being relied on for detail
127. PERSONAL
 COMMUNICATORS • Values emotional language and connection • Finds value in assessing what people think and feel • Good listener and diplomat • Builds deep relationships; is the “glue”
128. WHAT TYPE OF COMMUNICATOR ARE YOU? Analytical Intuitive Functional Personal
129. Try to identify communication styles/ preferences and adjust your approach
130. When all else fails…
131. Make public announcements
132. Invoke Contractual Clauses http://ngenworks.com/business/the-pause-clause/
133. QUESTIONS?
134. ROUND TABLE
135. BRINGING YOUR SKILLS TO REAL WORLD PROBLEMS
136. FOR EACH PERSON 1. Share a challenge you are currently facing (or recently have faced) 2. Discuss how you might approach it using techniques discussed today 3. Commit to a first step you will take
137. FIVE MINUTES
138. SWITCH
139. FOR EACH PERSON 1. Share a challenge you are currently facing (or recently have faced) 2. Discuss how you might approach it using techniques discussed today 3. Commit to a first step you will take
140. FIVE MINUTES
141. SWITCH
142. FOR EACH PERSON 1. Share a challenge you are currently facing (or recently have faced) 2. Discuss how you might approach it using techniques discussed today 3. Commit to a first step you will take
143. FIVE MINUTES
144. SWITCH
145. FOR EACH PERSON 1. Share a challenge you are currently facing (or recently have faced) 2. Discuss how you might approach it using techniques discussed today 3. Commit to a first step you will take
146. FIVE MINUTES
147. SWITCH
148. FOR EACH PERSON 1. Share a challenge you are currently facing (or recently have faced) 2. Discuss how you might approach it using techniques discussed today 3. Commit to a first step you will take
149. FIVE MINUTES
150. FEELING GOOD?
151. Q&A
152. THANK YOU! brettharned.com brett@brettharned.com @brettharned