What's Your Problem? Creating a Project Brief to Build Consensus with Doreen Hinton, Autodesk
•Download as PPTX, PDF•
1 like•106 views
Do you see a problem that is so obvious that everyone should see it, but they don’t? Do you have great data about a pain point for your customers, but don’t know where to go with it? In this session, we’ll talk about project briefs — what they are, and how they can be an invaluable tool for building consensus and getting your stakeholders and teams on board. In this session, you will learn: 1) How to pull together various data points into a cohesive project brief; 2) How to use a project brief to effectively present the problem/issue; 3) And, most importantly, why a project brief isn’t the right platform for solutioning. Presented November 29, 2018, at Quadrus Conference Center for Information Development World 2018.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What's Your Problem? Creating a Project Brief to Build Consensus with Doreen Hinton, Autodesk
Similar to What's Your Problem? Creating a Project Brief to Build Consensus with Doreen Hinton, Autodesk (20)
More from Information Development World
More from Information Development World (20)
Recently uploaded
Recently uploaded (20)
What's Your Problem? Creating a Project Brief to Build Consensus with Doreen Hinton, Autodesk
- 2. What’s Your Problem? Creating a Project Brief to Build Consensus Doreen Hinton, Product Manager Autodesk
- 4. • How do I use a project brief to effectively present a problem? • What are various data points I should use for my project brief? • Why can’t I use a project brief to provide a solution?
- 5. The Brief
- 6. BRIEF (presents issue) Measures Success (tangible results to resolving issue) Provides Quantifiable Data (validates issue)
- 7. Who + What: • What is the issue? • Who is affected? • What is customer benefit? • What is company benefit?
- 8. The Data
- 9. Someone needs to fix it This doesn’t work I don’t like it It’s BROKEN This is awful Who did this?
- 10. Direct customer feedback CSAT/Qualtrics User Research
- 11. Competitive Analysis Case/Ticket DBs Other internal sources
- 12. The Solution (or NOT)
- 14. Is your seatbelt on? Let’s check the fuel pump What about the spark plugs? Could be the battery…
- 15. EXAMPLE
- 16. What is the issue? What is customer benefit? What is company benefit? What is the measure for success? Who is affected?
- 17. There is currently no solution for customers or partners who want to do x. The current manual process requires customers to do x by completing and signing a form which must be scanned and returned; customers are also required to complete a Customer Service Assistance request and open a service ticket. The SLA for this process is currently 3 business days. Provide a self-service to allow customers & partners to do x instantly without involving customer support. Doing this would shorten TTR (Time to Resolve) from 2 to 5 business days to minutes and reduce 80% of English case volume for doing x. In FY18, a total of 10,397 cases were opened for doing x. Total time to resolve varied from 2.39 to 5.01 days (see below, 6. Analytics for details)
- 18. What is company benefit? What is customer benefit?Who is affected?What is the issue?
- 19. SUMMARY: • Use a project brief to effectively present a problem • Data points should be available, appropriate to use for the project brief • A project brief isn’t a way to provide a solution
Editor's Notes
- SLIDE #1 INTRO I’m Doreen and I’m currently a Product Manager at Autodesk with many years’ experience in (consumer) software and the digital space. I’ve held various roles from Producer to QA Manager to my current role as Product Manager on the Digital Help team. And I’m here today to talk to you about Project Briefs and how we can use them to build consensus.
- SLIDE #2 So, let’s start with a regular, every-day analogy: How many people here have a car or had a car at some point? Okay, so hopefully we can all relate to this one: You get in your car in the morning to get to work, but it won’t start. You call a mechanic and you start complaining – loudly – that the car ‘isn’t working.’ Is this effective? Will yelling about the problem help your mechanic assess the issue and fix it? On the other hand, what if you called and said, ‘the car won’t start’ -- what will he say in response? She or he will like begin asking you some questions. What will their questions be? From audience: i.e., what year/make/model, Did it make a sound? Did it try to start but was unsuccessful, or did it make no sound at all?, etc., etc. So – can you see where we’re going with this? If you are experience a problem, you want others – especially the people who can help solve the problem – to understand EXACTLY what that problem is. You want to “bring them along,” so to speak. And this is effective, because it leads to better questions rather than defensiveness and delays: what steps did you take to get there? Did it happen 100% of the time?, etc. – asking those questions up front helps us – believe it or not - to get to the answer (and hopefully, a resolution) faster.
- SLIDE #3 Today, then, we’ll talk about how to do that with a “project brief.” You’ll learn how to use one effectively, we’ll talk about some data points you should use and we’ll talk about why it’s important to NOT use a Project Brief to present a solution.
- SLIDE #4 The first thing we want to know about a brief is how brief is a brief? And how do we structure it? Much will depend on your company’s own processes and standards, but ultimately, there are some basic elements to include in the structure of your brief. Let’s talk about those..
- SLIDE #5 First, of course, you’ll want to keep it brief. There’s a reason why it’s called a “brief” and not a “novel!” This will ensure your audience will actually read your brief, it will keep them engaged and understanding of the issue or challenge you’re presenting, and it will ultimately help shore up their buy-in. Quantifiable data is important – referring back to our broken car analogy – we know that issues can be “arguable” or seen as a “matter of opinion.” But when you back up your assertions with actual data, then the “opinion” becomes less arguable. It’s similar to our teachers telling us to ‘cite your sources’ in school. Lastly, you want to round-off your brief with specific ways in which success can be measured. So, you are presenting an issue, let’s say, but you’re also showing WHAT BENEFIT comes from solving that issue.
- SLIDE #6 Ultimately, your Project Brief should answer some key “whos” and “whats” – you want to clearly state what the issue is, talk about who is affected by it and – importantly, talk about what the benefit to your customers or company might be. Of course, ideally, resolving the issue or problem would benefit both your customers and your company.
- SLIDE #7 Let’s look at why it might be important to include quantifiable information – or data – in your Project Brief.
- SLIDE #8 Does this look familiar to anyone? How many here have heard a complaint phrased as a problem? Statements like, “this is awful,” “it’s broken” or “I don’t like it” isn’t really helpful, especially because it’s not quantifiable. A project brief isn’t just a complaint in writing – it’s a clear, concise problem statement. In order to back up or reinforce your problem statement, you’ll want to get actual, real data that is both quantifiable and actionable.
- SLIDE #9 Some great areas to begin looking for data for your brief would be: CSATs, user research or any other ways your organization might be collecting direct customer feedback.
- SLIDE #10 Internally, in your back-end systems, there might be case creation or ticketing data you could look at; there very likely is other information out there that you may not know about – so partnering with your analytics, user research, customer support – even product marketing teams is always recommended – they are usually your best advocates for not just discovering data, but interpreting that data appropriately for the case you’re making.
- SLIDE #11 Now that we’ve talked about a brief and what it is and what it should include, let’s talk about what it isn’t.
- SLIDE #12 So, let’s go back to our car. It’s broken and I’m talking to a mechanic: he or she is someone who might be able help solve the problem I’m having. The problem is that it won’t start. Now, what if I told the mechanic, “The car won’t start, so you need to fix the transmission,” or “the car won’t start so you need to fix the starter”?? What is the mechanic likely going to do? They’ll fix the starter or they’ll fix the transmission. But was that REALLY the problem? Imagine spending the time without a car, the money to have it fixed ONLY to find that didn’t resolve the issue. Now I’m mad and I have literally gotten nowhere. AND we could have gotten into a positive feedback loop and wasted LOTS of time and LOTS of money. That’s why we don’t provide solutions in Project Briefs.
- SLIDE #13 I’m not a mechanic – it really isn’t the best idea for me to dictate to the mechanic the mechanic – the subject matter expert in this case – what to do. It’s the same with your Project Brief. If you prescribe a solution, is it the right solution? Is the only solution? You may or may not have all the information or expertise to know. You may be AN SME – but are you the only one or even the right one? There are other people in your team, your division, company, and so on – who may have data and perspectives you don’t. If you offer a solution in your brief, you may be eliminating the possibility of THE RIGHT solution.
- SLIDE #14 Okay, but enough with the car analogy. Let’s look at a real-life example of a project brief and do a little exercise together.
- SLIDE #15 Here’s an example of the template my team currently uses. This is on a Wiki and there is a whole set of internal processes around this, but all the project brief elements we’ve talked about are there: the “whats” of what the issue and benefit, the “who,” as in who it affects and so on. There are other points here, too, that are specific to our process; you may need to include information that’s relevant to YOUR internal processes – and that’s fine. The point here today is that some elements are optional – but some are not. Hopefully, I’ve been able to show you why.
- SLIDE #16 Here are example statements from an actual brief, albeit redacted. Let’s give everyone a moment to read them. Have we answered our four main questions? First, let’s refresh our memory of those questions; can anyone remember what those are?: [audience participates] What is the issue? Who is affected? What is the customer benefit? What is the company benefit? So does these statements answer those questions? [audience participates] What do we think – yes or no?
- SLIDE #17 And the answer is YES. When we break those statements out into the various fields, we see that we have answered those four critical questions. (By the way, that’s why sometimes forms are a good thing). And just so we know, this Brief was indeed approved and we are currently working on the solution. We just launched the first phase and the second will launch next week. We successfully presented our case!
- SLIDE #18 So, in conclusion, we’ve talked today about how to: Put together an effective project brief Include data points in your brief and Why it’s important to NOT use a Project Brief to solution Thank you for your time and attention.
- SLIDE #20 Are there any questions?