Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

Overcoming & Managing Project Challenges Workshop

Brett Harned
January 08, 2018

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.

Brett Harned

January 08, 2018
Tweet

More Decks by Brett Harned

Other Decks in Business

Transcript

  1. DIGITAL PM WORKSHOP: OVERCOMING & MANAGING
 PROJECT CHALLENGES JANUARY 8,

    2018
 TRIANGLE UXPA PRESENTED BY BRETT HARNED
 [email protected] | @brettharned

  2. 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
  3. 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

  4. 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?)
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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)
  15. 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
  16. 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
  17. 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)
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. Change management is the process, tools and techniques to manage

    the people side of change to achieve the required business outcome.
  33. 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
  34. 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
  35. UNDERSTAND: 
 WRANGLE DOCUMENTS • Scope • Strategy/Creative Brief •

    Requirements • Project Plan • Status Reports • Deliverables
  36. 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
  37. Let me see what we can do within our scope

    and get back to you with next steps.
  38. 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.
  39. 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
  40. 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.
  41. 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
  42. OTHER ITEMS TO DISCUSS If scope changes, these things may

    change too: • Timeline • Requirements • Budget • Resource availability • Quality of work
  43. 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
  44. 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
  45. 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
  46. 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
  47. 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
  48. 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
  49. 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?
  50. 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
  51. 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
  52. IDENTIFY PROJECT STAKEHOLDERS • Project Owner/Core Team • Primary Stakeholders

    • Secondary Stakeholders • Management • Executive
  53. 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?
  54. 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
  55. 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?
  56. 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
  57. 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
  58. 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
  59. 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?
  60. I’m concerned about this sudden change in timing. Can I

    ask why we’re being asked to change our plans?
  61. I’m happy to sit down and discuss our process and

    the associated effort required…
  62. Wrapping up the current planned work in three weeks will

    be virtually impossible, but let’s discuss possible alternatives…
  63. 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?
  64. ANALYTICAL 
 COMMUNICATORS • Prefer facts and data • Prefer

    specific language, not vague • Like communication to be unemotional; logical and dispassionate
  65. INTUITIVE 
 COMMUNICATORS • Thinks big picture • Wants to

    get to the point; not about details • Enjoys challenging convention • Can be frustrated by detailed conversations
  66. 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
  67. 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”
  68. 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
  69. 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
  70. 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
  71. 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
  72. 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
  73. Q&A