BI Blueprint: How to Map Your Project
•Transferir como PPTX, PDF•
4 gostaram•2,203 visualizações
A BI Blueprint is a comprehensive product roadmap for your BI initiative. Get best practices for creating a blueprint and using it to launch your analytics project. Learn more with The Definitive Guide to Dashboard Design at https://goo.gl/2IPpZL.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Logi Analytics
Mais de Logi Analytics (18)
Último
Último (20)
BI Blueprint: How to Map Your Project
- 1. BI Blueprint: How to Map Your Project Rebecca Gow
- 2. #Logi16 Rebecca Gow Solutions Architect Professional Services Rebecca.Gow@LogiAnalytics.com ABOUT ME 2
- 3. Matt Dwyer, VP Product Management BLUEPRINT IN THE WILD:
- 4. #Logi16 The Blueprint is a comprehensive product roadmap for your BI initiative. Why do you need a map? …if you don’t know where you’re going or how to get there... You may not get there without one. BLUEPRINT IN A NUTSHELL 4
- 5. #Logi16 When you are: Launching an enterprise-wide BI initiative Introducing analytics into a current product offering Rolling out the next phase of a BI project Re-designing a current analytics offering WHERE CAN I USE A BLUEPRINT? 5
- 6. #Logi16 THE BLUEPRINT METHODOLOGY 6 Talk to the right people Your target audience, not just your business stakeholders Find out how they use information How you ask matters for the answers that define your solution Connect the dots Steps 1 and 2 give you everything you need for your roadmap
- 7. WHO NEEDS INFORMATION? Defining your audience and project support
- 8. #Logi16 Your audience comes first ahead of all other stakeholders. If you don’t design for them, you risk building a product they won’t use. To identify and prioritize your audience, ask: Who needs this? Why do they need it? How urgent is the need? WHO ARE THE RIGHT PEOPLE? 8
- 9. #Logi16 Break your audience down to highlight user personas and help identify who you’ll need to interview. Consider: Distinct teams or groups of users – does this solution need to serve departments in an org? Teams by shift on a production floor? Unique roles – these often become your user personas by default Types of use – are there “power users” in your audience accustomed to self- service options? Administrators who control data inputs? WHO ARE YOUR USER PERSONAS? 9
- 10. #Logi16 Include anyone who may be impacted by your product – whether they’ll use it or they support the people who will. Talk to: Technical SMEs – IT, architects, DBAs, development operations, QA Business SMEs – people with deep knowledge of an area of the business that needs the solution Project sponsors – not only official sponsors, but also people from whom you’ll need resources to launch the product successfully OTHER KEY STAKEHOLDERS 10
- 11. #Logi16 Two to three days of interviews with your project sponsors, audience personas, technical SMEs and other stakeholders – in that order – usually yields what you need to compile a Blueprint. Sample Agenda: ALIGNING INTERVIEWS Day 1 Session Participants 9 – 11AM Project Overview Project owner & sponsors 11AM – 5PM User Interviews 2 – 3 people from each user group Day 2 9 – 11AM Technical Interviews IT, DevOps, technical SMEs 3 – 4PM Initial Findings Project owner & sponsors 11
- 12. HOW DO THEY USE DATA? Learning what BI means to your audience and how to provide it
- 13. #Logi16 Keep questions broad & non-technical. Some starter questions: 1. Describe your role. 2. What’s an average hour / day / week on the job like for you? 3. Who do you interact with most often? What do they need from you? 4. What systems / reports / sources do you use? 5. What metrics do you need? How do you measure performance? 6. What are some challenges / frustrations in your job today? GETTING TO KNOW YOUR USERS 14
- 14. #Logi16 Getting good info out of your interviews is key to a clear Blueprint. Three tips for a successful interview: 1. Keep an Open Mind – if you go in with an agenda, you’ll miss critical info 2. Ask Open-Ended Questions – this gets you the most information possible 3. Limit Your Interview Audience – you’ll typically get better results with a smaller, focused group (2 – 3 representatives of the same persona or role) than with everyone from the team in the room INTERVIEW TECHNIQUE 15
- 15. #Logi16 Once you’ve completed interviews, review your notes for: What metrics & key insights each of your personas uses Databases & systems they access today for data What they are and aren’t allowed to access What they like today – and may be worth keeping in the new solution Frustrations & obstacles – slow performing reports? A specific insight they need has to come from another team and takes weeks? DIGGING UP THE GOLD 16
- 16. #Logi16 COMPONENTS OF A LOGI BI SOLUTION DATA UI INTEGRATION SECURITY INFRASTRUCTURE 17
- 17. #Logi16 REFINING YOUR SOLUTION: Architecture 18 DW DB1 DB (future) ANALYTICS PORTAL / PARENT AUTH Draw it up and socialize: Data Sources Application Integrated Systems Security Frameworks Interactions
- 18. #Logi16 REFINING YOUR SOLUTION: UI Mockups 19 Keep It Simple – concept, no detail Start Your Design Here – mockups serve as the basis of your design Iterate
- 19. Completing your Blueprint and plotting your route to a successful launch CONNECTING THE DOTS
- 20. #Logi16 What you need for your roadmap: Key Problems / Needs – what’s driving the project? Target Audience – who needs this and why? Key Goals – what should the completed product have accomplished? Key Functionality – what features “make” the solution? Solution Design – what is your solution stack and architectural design? Timeframe – when is this needed? WHAT ARE THE DOTS? 22
- 21. #Logi16 STRUCTURING YOUR PROJECT Two common approaches to balance data access with application development: 23 ANALYTICS DATA TIER ANALYTICS APPDATA TIER Milestone 1 Milestone 2 More Time for Dev Balanced Resourcing Less Time for Dev All Hands on Deck Parallel Dev
- 22. #Logi16 Key considerations for your project schedule: involve your users, allow for design iterations and start data validation early. DEFINING YOUR SCHEDULE 24
- 23. #Logi16 Staffing a BI project for success: Data Development Team – data architect, developer, DBA for modeling data, developing data stores, designing ETL and tuning for best performance Data Validation – business SMEs, potentially your user representatives for defining source data and validating numbers UI / Design Team – especially for embedded products where seamless style and UI is required, also for designing visualizations for global audiences STAFFING YOUR PROJECT 25
- 24. #Logi16 Common risks and how to mitigate them: X Nice Dashboard, No Data Don’t let your app get ahead of your data – structure your project to ensure there’s always something to show and validate at each review X User Count = 0 Involve your audience early and often, starting with the solution design and through frequent reviews during development X User Count = The World Monitor and tune for best performance! Log enhancements and iterate using the Blueprint method for future phases BUMPS IN THE BI ROAD 26
- 25. #Logi16 A completed Blueprint delivers: Requirements Analysis – detailed analysis of the problems / needs driving the project, the goals of the solution and its target audience Solution – architecture and its components: data sources, security considerations, integration points and conceptual user interface designs Implementation Plan – delivery plan including milestones, development schedule and resourcing WHAT DO YOU GET? 27
- 26. Matt Dwyer, VP Product Management BLUEPRINT IN THE WILD:
- 27. ANY QUESTIONS?
- 28. Interested? Contact your sales rep for more information or to schedule a Blueprint: salesteam@logianalytics.com
- 29. Learn more with The Definitive Guide to Dashboard Design
Notas do Editor
- I’d also like to introduce Matt Dwyer; he’s the VP of Product Management at FranConnect, and is graciously donating his time today to share with us how the Blueprint approach helped FranConnect deliver analytics to their customer base.
- Think of a Blueprint as a roadmap for your BI product – it defines your destination, tells you how to get there and what that takes in time and resources. Few projects succeed without a plan. The Blueprint methodology gives you that plan tailored to the needs of BI solutions.
- Where might you use a Blueprint? We most often apply this methodology for customers who are: Beginning a push to become data-driven organizations and seeking a vision for enterprise BI Want to introduce embedded analytics into their product and need to understand what that looks like Are planning the next phase or next generation of a BI project – what can we do next? Have limitations or poor performance in a current product and want to re-design properly to fix those issues - Matt: Q1: With this in mind – Matt, would you explain what prompted FranConnect to take the Blueprint approach? (highlight use case)
- Thanks, Matt. Given the aggressive timeline in front of Matt, how do we help him design a plan quickly? At the end of the day, a Blueprint requires three things (in order): Find and talk to the right people: not just your sponsors and your technical experts, but most especially your audience – whether this includes your customers or your co-workers – the people with the data problem who’ll benefit from your product; find those people, then… Find out what information they use to do their jobs: interview those people and get to understand what they need to know and why, and where they get that knowledge; And once you’ve done both those things, connect the dots in that information to define your roadmap. I like how I just made this sound easy.
- So let’s break this down, starting with the first step – who are the right people to talk to?
- First and foremost, your audience – or representatives of your audience. I can’t emphasize this enough; I’ve had customers tell me, “I wouldn’t bother talking to our users, they don’t know what they want.” I’ve yet to find this to be true. I have found that if you don’t involve them in your requirements gathering, you risk building a product that isn’t relevant to them and not seeing user adoption. You want to draw out what they want and translate that into your design. If you don’t yet have a definition for your audience – just a problem you’re hearing about – now is the time to find out who has this problem; why they need it solved; and how urgent their need is. I ask the last because, in cases such as an enterprise BI initiative, maybe there are 9 different departments who’ll eventually be on board, but 2 or 3 needed it yesterday and nothing is working and PANIC! – those are the folks you’ll want to talk to soon, and maybe the other departments can be tabled for later phases.
- Next, break your audience into personas. Can I get a show of hands from you all – are you familiar with the term persona? At a basic level, these are groups of common actions and activities shared by a percentage of your users. Once you find these, you can identify people who fit these personas to talk to. How to break down your audience? Look at distinct teams or groups of users, such as company departments, teams by production line on a manufacturing floor; or roles – these often end up being your user personas by default such as roles within a sales team – Sales Manager, Sales Operations, Account Executives, each with distinct needs out of the solution. Also consider types of use – do you have people who today are used to getting data and analyzing it themselves in all kinds of homegrown ways? Or are all of your users going to want to log on, see something has changed and then go away and fix that? - Matt: Q2: For Matt - who are the personas in the audience for FranConnect’s analytics?
- Once you’ve identified people who fit those personas – line up your other stakeholders. This is anyone who may be impacted by your product. Especially: your technical subject matter experts. Anyone in an IT capacity who supports where the product will live or be hosted; anybody with expertise on data sources, other system architectures; development leads on what can be done by when. Also: your business SMEs, who may not be users of your product but have deep knowledge into the business of your audience. You want them to verify your assumptions and provide context. Project sponsors: anyone involved in deciding who contributes and supplies what they need to get the product built.
- - Now, you’re going to interview everyone. The format will be a little different for your personas than for everyone else, and it’s those interviews where you’ll really get the gold. When we at Logi deliver Blueprints, we usually conduct the interviews within a 2 – 3 day timeframe – kinda grueling, but it has the advantage of getting everyone together and letting ideas bounce around. In the sample agenda here: we kick things off with a project overview, which is our review of what’s prompted the effort, set goals, raise constraints; then a session with users from each of your personas, 2 hours if you can persuade everyone to step out of their day jobs that long, 1 if you can’t; then talk to your technical experts, by which point you’ll have first thoughts to take back to the project sponsors. You want the info from your user interviews to take into the technical discussions.
- Q2: Who are the personas using FranConnect’s analytics offering? Other stakeholders?
- You’ve now finished step 1 – you know who the right people are; now for step 2 – find out how they use information today in their jobs, and how do you get it to them?
- First off: take notes. Take lots of notes. Or if you slack off about taking notes (like me), record the interviews if you have to. But trust me, take notes. Second: you want to give users the chance to answer broadly, and follow answers down lines of inquiry as they come up. This is a sampling of the questions I’ll ask when kicking off an interview: Can you describe your role for me? What does an hour or day or week in the life look like for you? (Frequency can be important – we all use data at different times for different reasons.) Who do you work with? What do they bug you for? What do you bug them for? What systems or sources or reports do you go to today for information or submit information to? What metrics do you monitor? Better yet: how do you measure performance in what you do? How is your performance measured? What are some challenges in what you need today? < this can be a tricky question that gets you more than you were looking for… but can also get you “well I’m really tired of being asked for a list of current customers when the report that tells me that takes 2 hours to load”.
- (- Also… take notes.) When asking these questions, keep some techniques in mind to get the most out of these sessions. First: there are a lot of software solution and product professionals in the room today – we’re used to coming up with answers and very often we’ve got an idea up front. You want to set that aside for these sessions; if you take that pre-conceived vision into the interviews, we might dismiss some great ideas or even a change in course subconsciously. So as much as possible – check what you’d like to deliver at the door and be open to the unexpected. Ask Open-Ended Questions – as you saw in the starter list, most of those questions left the door open to the user to explain a lot. Maybe they explain more than you need, it’s better than only yes or no. Lastly: limit your interviewees to 2 or 3 representatives of each persona – and interview each persona group separately. You’ll get better, clear results than if you try to talk to everyone at once.
- …Did you take notes? Good, because now you want to compile all those notes and find all the pieces of your solution. That’s the key insights that your users need to do their jobs, where they get data today, what they can see and what they can’t, what they like today – you don’t want to mess with these things if possible; and lastly what’s in their way right now – slow-performing reports? People they have to bug in person? KPIs that aren’t defined?
- In all of that, you’ll find the components of your BI solution. Data: any data sources your audience uses today (or needs) – this is more than just databases and spreadsheets; maybe it’s even word of mouth or on paper. I have a Blueprint customer who’s using the approach to plan to free their audience from a paper habit; key information is jotted down on clipboards and then shared every morning in a meeting. Get names of all of these sources so you can go to your technical discussions for definitions. - UI: you want to get this right – people ignore design that ignores people. In a BI context – this is, should it look like a dashboard? Should it appear as a chart or a gauge as a table? How will users interact with it? I recommend mocking this up in quick and dirty design sessions – I’ll talk through that in a bit. - Security: this includes who can get access to the product, and what they’ll be allowed to see. Your personas help define this, then confirm with your business leads and SMEs. - Integration: will this solution be embedded in another product? Does it need to interact with custom security frameworks? Note these systems as well. - Infrastructure: what servers and system does everything you need currently live on? What might you need? Capacity planning – the detail on what you might need and how much it’ll cost and so on – probably isn’t practical at this stage, but you’re doing the groundwork for it here.
- - Draw it up. What does your architecture already look like?
- Good UI is critical to user adoption. Your users may not be able to draw up a design just yet, but the info they give you helps get you a picture of that design. Mocking it up is one of the best ways to get it in front of everyone for agreement. I frequently draw up designs on a whiteboard during interviews or mockup something simple in PowerPoint – this example is one I mocked up in a tool called Balsamiq and shared after the interviews for feedback – based on what I heard, here’s what I’m seeing, does this make sense to you? I also recommend not doing this early in a discussion, so as not to guide your audience: let them guide you first through their answers. Key points for mockups: keep it simple. You’re conveying a concept here, you don’t want to show actual numbers or placement or labels here or that’s what people tend to focus on. These can serve as the basis for full wireframes later. And, iterate as needed. You might do some of this during your interview stage, you might send out mockups for review and follow-up before completing your roadmap. - Matt: Q3: What was FranConnect’s solution as defined by the Blueprint process?
- Q3: What was FranConnect’s solution as defined by the Blueprint process?
- Don’t forget your data. Ensuring user adoption – involve your target audience, preferably through its representatives already interviewed, frequently throughout design and development so that you get regular feedback from them and stay on the right track, and so that they’re engaged and excited about the outcome. Controlling scope – this is the opposite problem and one that’s the good kind to have. Just avoid being buried under enhancement requests. You can iterate using the Blueprint method. Log enhancements and go back and interview the users who submit them to find out how to prioritize across future project phases. Design, plan, go.
- Matt: Q3: How did the Blueprint approach help mitigate risk / set the project up for success? What was the outcome of the project? Lead into FranConnect demo > Matt.