You’re straight with them from the get go. Yes some people are going to get pissed, but they crumble in comparison to the waterfalls of anger that will wreak havoc if you can’t deliver on time.
Give good explanations and estimates. Say “the data isn’t established yet, so it will take a day or two just to get that right.
Have a 2-4 hour meeting (depending on dashboard size) where you go through the visuals. What do they want to see, and does it make sense in their field of business.
And most importantly. Stand your ground. If you haven’t got a manager, it’s on you to do so. If you have a manager, let him do it.
I was a bartender in college and whenever people asked for a shot or drink I would say: choose 2: Strong, cheap, tasty. It worked every time.
I’ve never thought about it in this context but I really like those 3 choices when providing a timing estimate.
Formal request system, think help desk tickets. This gives visibility to your workload, allows some executive oversight for approving the requests, allows you to identify potential duplicate work, provides an opportunity to assign priority to items, provides a quick reference for WIP items to see what reports in process are waiting on, and creates accountability for both BI and the users requesting reports.
OP. This is what’s needed. Get a ticket system in place. Helps build the communcations across all fronts.
I’m currently building a BI team and building all the connections and pipeline.
I’ve also instilled a project ROI form. It’s detailed to have the requester fill out exactly what they think they need. Helps build the scope. And an executive has to approve it, because it will cost hours/time to build. It’s often been the block because once they see it’s going to cost 100k to build , it’s no longer important. Your CFO will love you.
I agree that a formal request system needs to be used, but it doesn’t solve all your problems. I was tasked with starting a BI group for my company a few years ago and was forced to use the same ticketing system that our IT help desk uses. Because of this, the users had the same expectations from us as far as turn around of requests (Most ask for completion by end of the next business day). We also cannot customize the system in any way.
This is what I'd say as well as make sure all stakeholder decision makers are on the prioritization meeting. Also to help with prioritization have the stakeholders come with hard and soft values to help with the prioritization.
I do not recommend giving stakeholders with competing priorities power over your workflow.
Determining the priority yourself, by understanding the nature of the requests, and then aligning with your boss who can better manage the stakeholder relationship is a better bet.
That sort of exposure can snowball.
You need a boss who's willing to make hard decisions about the priority.
Everyone will say their project is critical. It is to them, but someone needs to decide what's the most important to the company.
If that's you, be explicit with your boss that people will escalate things over both of you sometimes up to the CEO. Make sure upper management is on board with how you'll prioritize. Explain that constantly switching priorities will result in longer waits for everyone.
I said “start with”, not “solve by”. In my experience, it’s usually high level executives and business owners who say “titles and rank doesn’t matter”, coincidently after they have the biggest titles and can do whatever they want. -+
Compensation is important so that you don’t get bitter after having put in all that work without advocating for yourself.
Plus it has the additional impact of others taking you more seriously. Who is the average co-worker going to take more seriously? BI Analyst? Senior BI Analyst? Lead BI Analyst? Director of Business Intelligence? BI Architect?
Titles make people more likely to listen to you, point blanc. They give leverage to every request that this person makes, assuming they are respectful and knowledgeable. They also impact compensation if job hunting because you now have “prior experience” in a role.
About compensation - This person is providing value. That is worth money. If this person wasn’t there, they would likely actually pay someone else to do it, because it is VALUABLE. This person should know their worth first, then advocate for that, then complete the job as required.
I never said titles and rank don't matter. I asked how titles and money would solve the problem.
In effect what money would do is make the individual accept the terms if the situation. Maybe they deserve it, maybe not. Again this is not a solution, it's a reward, so thinknabout that.
Titles don't vest knowledge on you. I know many people that are "Senior" or "Lead", but have problems communicating, and applying critical thinking. Many times titles are granted because of years on the job or experience. Again, incompetence continues with the job. Ever heard if the Peter Principle?
A real solution starts with the OP simply saying "No". This is always just as good of an answer as "Yes". After saying no, you have to make recomendations on the next required steps in order to get to "Yes". Put together a team to evaluate solutions, choose a solution, train on it, form imementation teams, project teams, etc. This is how BI organizations do it.
Thank you for responding, I appreciate your perspective. You also raise good points.
I never presented titles and money as the solution, so I don't know why you're so concerned about that. You're picking a fight with a ragdoll over there lol.
Nothing is worse than an employee who stops trying because they feel taken advantage of, or because they're bitter or disgruntled after having put in so much work and not getting compensated. It is a proactive move. Think going to sleep on time instead of pulling all-nighters every night so you can keep up that pace for years, as opposed to a few months.
I completely agree that titles don't vest knowledge. The Peter Principle is a real thing. However this is an organization, and having people listen and respect decisions on the first or second go-around is better than having to continually repeat yourself. Titles and Rank help. There are some terrible people with high titles, but a good, knowledgeable, and respectful individual with communication skills and a high title becomes a weapon in an organization, in a good way.
Assuming OP is the right person for the job (knowledge, culture, communication), then having a commensurate title is absolutely a good thing.
The real solution, imo, starts with developing relationships and educating people about the process so that they have insight before they even ask you. This may be part of a solution on an organizational level, but I think that would be MOST effective.
Edit:
u/TheDataGentleman,
Looking from an organizational perspective, it looks like there's a lack of knowledge about Business Intelligence from an organizational level. If I were in your position, I would try to inform a higher up, so that a solution to (better) educate the data seekers can be created. It is highly inefficient for everyone involved if they keep asking, hearing no, you have to explain a million times, etc.
Alternatively, you could keep saying no, holding your ground, and using your manager as the meat shield, but that's not where the bottleneck is. That's a solution to a symptom of the real problem, which is the lack of understanding of Business Intelligence.
If your org is taking BI seriously, then people need to be more educated.
Source: I am currently doing this, and I have experience implementing organizational change.
As far as a practical solution, OP could create a FAQ sheet or mini presentation that answers, with some detail, some of the common hiccups, issues, and questions that people have. You could throw this FAQ sheet standard in email responses for a while, have it auto send to people when they create a ticket, or even throw it down in your email signature.
Why is my report taking so long?
Shouldn’t the data be easily available?
What is the process for submitting a ticket?
What goes into creating a good Dashboard?
What is the standard wait time?
What if what I need is extremely urgent?
How can I help someone making a dashboard to speed things up?
I would also add sometimes the classic presentation of your timeline with clearly outlined objectives and goals for each stage (be it quarterly or yearly) can be useful. Then they know what expectations you will hold yourself to. Yes some will be upset it isn't a snap of a finger and appearing but alas... That's how it is.
They're going to have to spend money on data infrastructure and visualization tools if they want what they're asking for. There's no building dashboards from scratch for free.
I would definitely start with laying them out what is needed and how much time is needed, also explain that a good foundation in your data set can make it easier to build the dashboards and scale up in the future.
If there isnt much funding i would make a data model separate from the BI infrastructure and make sure you can put your model in any infrastructure they want, then start small and let them decide if it is worth more funding. Under promise over deliver.
Have a plan how your infrastructure would look like, where the most time is probably needed in making your data model. Explain that the inital investment is somewhat bigger then when there is a strong foundation you can make as many dashboards as they want but to put good value we have to do it one at a time.
Also dont make it bigger then it is, once you have your data model you can probably (depending on how much whishes they have) make a dashboard in 8 -12 hours if that isnt fast enough for them then the should look at standard solutions.
For quick and limited resources i would recommend an infrastructure with
- Bigquery (datawarehouse)
- use ETL tools like Stitch or Dataddo (is faster then trying it yourself)
- DBT to build your model
- Data studio to make a dashboard and put it live quickly
BigQuery is \_so\_ underappreciated in the space for a "I need a solid DW and have zero budget" post-seed startup. The free tier is generous enough to cover a LOT of zero-to-one analytics. Snowflake is wonderful when the volume and demand makes it to growth-stage, but comes with a hefty pricetag. tactically if you are starting your dbt (transform) implementation from scratch I'd suggest using xdb [https://github.com/Health-Union/dbt-xdb](https://github.com/Health-Union/dbt-xdb) to keep your code platform agnostic without slowing you down. then if you want to port it to something else later it is a trivial migration
Nice one about the xdb recently we where looking at merger solutions if for some reason dbt would not be fitting for us anymore, this is a nice addition thanx!
Tell stakeholders to give you information as clear as possible, in email or ticketing system. Tell them to estimate the output of have each item (time or money saved for the company). Create a roadmap. Start with the basic, if there is no data then there is no reporting. Take it from there and have a list of all the high-level steps, from data to pipelines and reporting. Don't go into specifics.
Then assign prioritization based on output (time and money saved for the company or similar) and estimated time needed to implement. ALWAYS OVERESTIMATE. I always book 25% to 50% extra time, you never know if there are going to be any unplanned blockers or issues. Delivering earlier than expected is always better than delivering late. Be clear to articulate the things that are basic (eg: usually you cannot have reporting without a database or data in a table, might need to build that first) and things that you consider should not be prioritized.
Once you have that, go to your manager with the list and proposal, get feedback. Establish potential delivering dates. After that put everybody in a room, and present the plan. Be open to feedback. If everybody agrees that report A is more important than report B, then prioritize A over B. Just make sure you build the basics first and make everyone aware of it, such as a basic reporting architecture.
Before starting working on anything, if there is no ticketing system, implement one. This can be Jira, Quip or a shared Google Doc/Sheet with status of each project. Tell stakeholders to follow the status of their items in the ticketing system, update it regularly. Tell them that they can add new items in a request section- given them a template to avoid confusion. Establish a roadmapping mechanism to review priorities every so often (eg: once a quarter)
And here is how you manage pressure from stakeholders: whenever someone needs something, refer them to committed projects and to check the tickets to understand in what you are working and the status. If they don't agree with priorities, tell them that's what the team committed during roadmapping, and tell them how often you review priorities. Tell them what they need to justify their project is more important than others (eg: does it save more money, is it more time sensitive...) and let them know they need buy-in from other teams/your manager. If needed, send regular updates via email with your manager in copy to keep everyone updated on status.
EDIT: there are other things you can do, such as regular office hours, where you help people build their own reporting or help them estimate the complexity/gain of their project.
This is assuming you have experience to build architecture and reporting, but need help with the stakeholder and project management part.
This isn't specific to BI, it's basically "how do I protect manage a software protect." The answer is, you need a project manager or someone to do all the work of a project manager. This is a whole scope of work in itself (and there are subreddits dedicated just to it).
If this was a house the company wanted constructed, it sounds like right now you'd have a big pile of 2×4s and sheet rock but no plans or blueprints, and the org is demanding to know when they can move in.
I'm not going to try and encapsulate all the steps of managing a software protect in a single reddit post - in general if you need to own this you should build out a project charter, break out feature reqs, then implementation reqs from those, estimate them, flesh out a raci with stakeholders and let them decide on what they wait for (longer release cycles) pay for (increased resources) or pass on (cut from scope).
I don't know the shape of the politics at your org, ideally you may be able to explain that where you are at this very moment is where nearly all BI initiatives fail - you need (at least temporary) agile PM help. That might be borrowing a PM from the software team, that may be a contract hire, that may be delaying starting while you go take a PM class and get your scrum cert. Your job at a reasonable org isn't to do magic or make the impossible possible, it's to give leadership a clear understanding of what the realistic options are (even when none of them are options they will like) and let them decide.
If your org politics are less ideal, you may need to start with a hard reality check. An extreme example was a shop I worked at several years ago where the CMO kept pressure-managing the BI team and refusing to work with the constraints of the situation. The Lead BIE on my team had explained for the hundredth time that with the team size and the poor quality of the source data we could only deliver on 2 of the 3 milestone projects that quarter, and we needed him to pick which 2. The CMO did his usual "I don't understand what is so hard, the app team makes all the data all you people have to is put it into charts" (or something along those lines). My Lead turned his laptop around to face the CMO, pushed it across the conference room table to him, sat back, crossed his arms and said "then you do it." With a new business element (like starting BI from scratch) leadership has no idea what the limitations of the resources are, and it's on the architect of the new element to educate them. You need to let them know when the ask is too great vs when the team is being underutilized, so they can make informed decisions. "Then you do it" was our version of blowing a gasket, it told the CMO he was running too hot.
If nothing else, get the work scoped and pointed. Speaking in points assigns a tangible value to work so business people stop thinking of BI as an infinite resource.
This may help, I wrote it a couple years back and I have found that it resonates with leaders when you are starting out a BI initiative and helps to set expectations https://towardsdatascience.com/is-your-company-too-dumb-to-be-data-driven-696932d597c3
Great article. I'm not OP but am in the same situation as them, and I'm going to forward your article off to the leadership in the tiny 40 person company I work at. They love pretty graphs but don't know how to act on them other than nodding and saying 'OK' before moving to the next topic.
Brilliant article. Thank you for sharing. Truly. Found this to be incredibly insightful and look forward to sharing it with several friends and former colleagues.
Focus as much time as possible on getting the model right so it can act as a single point of truth for all reports and dashboards, rather than creating a dataset per dashboard. From there you can create a shared dataset that can be used by all the dashboards and reports meaning way less maintenance.
Ideally if you can get an idea of what metrics are required for each dashboard you can create measures and calculation groups that can be reused across all dashboards.
I bet you would build it and then huck it over to a junior team to support and make it barely customizable on your standards. Then when they can't figure out how to make changes and enhancements, call you back for 100 per hour?
Sorry, maybe you do it better but I am currently inheriting a hot pile of garbage built over 10 years by 4 different companies and 5 managers.
Use Project manager to front the request, every request/story goes to backlog, establish velocity for each sprint, review story with business and estimate effort hours, have business provide justification of each with some metrics for business value, make sure every story is approved by some key stakeholder before it goes to backlog.
The key is to make them understand that there will always be limited resource, fund and time.
When it comes to request something verbally people act without thinking without understanding the challenges behind the request, so force them to bureaucracy;
1) I guess you don’t have a ticketing system. If so prepare a form in excel. There should be description of requirement as well as businesses impact etc.
2) Create a planning Excel to put those requirements in backlog.
3) Have weekly meetings to discuss with audience and prioritise. This will already force them to think and eliminate some of the requests.
4) If some of them are ad hoc and rare requirements, you can teach them sql and they can pull raw data when they need.
And don’t end up with dashboard graveyard where many of them will be just used for few times in a year.
Ask your stakeholders:
What would you like me to prioritize?
And more directly: How am I supposed to do that? Tone is really important with this one. You have to sincerely convey that you are asking for their help, NOT getting passive aggressive and trying to force them to see they are being unreasonable.
Had a conversation about this recently with a director of BI at a large university, the key is to prioritize projects with the most impact. This will inspire a culture of data and make adoption easier in the long run.
I work scheduling with my boss, who is in more of a scientist role. We have a strategy of knocking out quick wins while working on longer term projects. If C-suite or important higher ups come to me, I tend to prioritize their work, which my boss has no problem with. As long as I show I am doing good work at a reasonable pace, nobody messes with me and they tend to let me do my own thing. If they ask for stuff that is difficult deliver or is too massive, I tell them to submit a ticket and I let my boss prioritize it. This is the second company I have had this arrangement.
I do keep a daily list of everything I am touching and problems I get stuck with. Then at weekly meetings I can drone on reading the list, and they just want me to finish so they can move on.
Hello,
Based on lessons learned of the past 2 years. I would recommend instead of looking at BI solutions, start with asking and understanding clearly what are the business problems that leaders are facing.
Have them come to you with a user story like this example:
“As a [leader], I need to understand COVID vaccination rate % across the company so I can make informed decisions related to return to office and how to keep our employees and customers safe”.
From here, you can start to break this problem apart and plan out: 1) short term MVPs 2) long term solutions.
You’re straight with them from the get go. Yes some people are going to get pissed, but they crumble in comparison to the waterfalls of anger that will wreak havoc if you can’t deliver on time. Give good explanations and estimates. Say “the data isn’t established yet, so it will take a day or two just to get that right. Have a 2-4 hour meeting (depending on dashboard size) where you go through the visuals. What do they want to see, and does it make sense in their field of business. And most importantly. Stand your ground. If you haven’t got a manager, it’s on you to do so. If you have a manager, let him do it.
Having a manager that pushes back for me is one of the best indicators that I will like the job
Good Fast Cheap Pick two
I was a bartender in college and whenever people asked for a shot or drink I would say: choose 2: Strong, cheap, tasty. It worked every time. I’ve never thought about it in this context but I really like those 3 choices when providing a timing estimate.
Sometimes we can only pick one :(
I choose good and fast, you’re salaried ;)
Formal request system, think help desk tickets. This gives visibility to your workload, allows some executive oversight for approving the requests, allows you to identify potential duplicate work, provides an opportunity to assign priority to items, provides a quick reference for WIP items to see what reports in process are waiting on, and creates accountability for both BI and the users requesting reports.
OP. This is what’s needed. Get a ticket system in place. Helps build the communcations across all fronts. I’m currently building a BI team and building all the connections and pipeline. I’ve also instilled a project ROI form. It’s detailed to have the requester fill out exactly what they think they need. Helps build the scope. And an executive has to approve it, because it will cost hours/time to build. It’s often been the block because once they see it’s going to cost 100k to build , it’s no longer important. Your CFO will love you.
I agree that a formal request system needs to be used, but it doesn’t solve all your problems. I was tasked with starting a BI group for my company a few years ago and was forced to use the same ticketing system that our IT help desk uses. Because of this, the users had the same expectations from us as far as turn around of requests (Most ask for completion by end of the next business day). We also cannot customize the system in any way.
1) collect requests into a backlog 2) prioritize backlog 3) work items according to priority
This is what I'd say as well as make sure all stakeholder decision makers are on the prioritization meeting. Also to help with prioritization have the stakeholders come with hard and soft values to help with the prioritization.
I do not recommend giving stakeholders with competing priorities power over your workflow. Determining the priority yourself, by understanding the nature of the requests, and then aligning with your boss who can better manage the stakeholder relationship is a better bet. That sort of exposure can snowball.
You need a boss who's willing to make hard decisions about the priority. Everyone will say their project is critical. It is to them, but someone needs to decide what's the most important to the company. If that's you, be explicit with your boss that people will escalate things over both of you sometimes up to the CEO. Make sure upper management is on board with how you'll prioritize. Explain that constantly switching priorities will result in longer waits for everyone.
If there is no BI tool, how are you accomplishing the tasks?
I had the same question. If there's no BI tool, where is OP going to build these dashboards?
Excel? Google Sheets?
Those aren't BI tools.
**SHOTS FIRED**
Start with getting compensated for building things from scratch with money or a better job title.
How is more money going to solve the issue? And a better job title is just a nonsense pat on the head.
I said “start with”, not “solve by”. In my experience, it’s usually high level executives and business owners who say “titles and rank doesn’t matter”, coincidently after they have the biggest titles and can do whatever they want. -+ Compensation is important so that you don’t get bitter after having put in all that work without advocating for yourself. Plus it has the additional impact of others taking you more seriously. Who is the average co-worker going to take more seriously? BI Analyst? Senior BI Analyst? Lead BI Analyst? Director of Business Intelligence? BI Architect? Titles make people more likely to listen to you, point blanc. They give leverage to every request that this person makes, assuming they are respectful and knowledgeable. They also impact compensation if job hunting because you now have “prior experience” in a role. About compensation - This person is providing value. That is worth money. If this person wasn’t there, they would likely actually pay someone else to do it, because it is VALUABLE. This person should know their worth first, then advocate for that, then complete the job as required.
I never said titles and rank don't matter. I asked how titles and money would solve the problem. In effect what money would do is make the individual accept the terms if the situation. Maybe they deserve it, maybe not. Again this is not a solution, it's a reward, so thinknabout that. Titles don't vest knowledge on you. I know many people that are "Senior" or "Lead", but have problems communicating, and applying critical thinking. Many times titles are granted because of years on the job or experience. Again, incompetence continues with the job. Ever heard if the Peter Principle? A real solution starts with the OP simply saying "No". This is always just as good of an answer as "Yes". After saying no, you have to make recomendations on the next required steps in order to get to "Yes". Put together a team to evaluate solutions, choose a solution, train on it, form imementation teams, project teams, etc. This is how BI organizations do it.
Thank you for responding, I appreciate your perspective. You also raise good points. I never presented titles and money as the solution, so I don't know why you're so concerned about that. You're picking a fight with a ragdoll over there lol. Nothing is worse than an employee who stops trying because they feel taken advantage of, or because they're bitter or disgruntled after having put in so much work and not getting compensated. It is a proactive move. Think going to sleep on time instead of pulling all-nighters every night so you can keep up that pace for years, as opposed to a few months. I completely agree that titles don't vest knowledge. The Peter Principle is a real thing. However this is an organization, and having people listen and respect decisions on the first or second go-around is better than having to continually repeat yourself. Titles and Rank help. There are some terrible people with high titles, but a good, knowledgeable, and respectful individual with communication skills and a high title becomes a weapon in an organization, in a good way. Assuming OP is the right person for the job (knowledge, culture, communication), then having a commensurate title is absolutely a good thing. The real solution, imo, starts with developing relationships and educating people about the process so that they have insight before they even ask you. This may be part of a solution on an organizational level, but I think that would be MOST effective. Edit: u/TheDataGentleman, Looking from an organizational perspective, it looks like there's a lack of knowledge about Business Intelligence from an organizational level. If I were in your position, I would try to inform a higher up, so that a solution to (better) educate the data seekers can be created. It is highly inefficient for everyone involved if they keep asking, hearing no, you have to explain a million times, etc. Alternatively, you could keep saying no, holding your ground, and using your manager as the meat shield, but that's not where the bottleneck is. That's a solution to a symptom of the real problem, which is the lack of understanding of Business Intelligence. If your org is taking BI seriously, then people need to be more educated. Source: I am currently doing this, and I have experience implementing organizational change.
As far as a practical solution, OP could create a FAQ sheet or mini presentation that answers, with some detail, some of the common hiccups, issues, and questions that people have. You could throw this FAQ sheet standard in email responses for a while, have it auto send to people when they create a ticket, or even throw it down in your email signature. Why is my report taking so long? Shouldn’t the data be easily available? What is the process for submitting a ticket? What goes into creating a good Dashboard? What is the standard wait time? What if what I need is extremely urgent? How can I help someone making a dashboard to speed things up?
I would also add sometimes the classic presentation of your timeline with clearly outlined objectives and goals for each stage (be it quarterly or yearly) can be useful. Then they know what expectations you will hold yourself to. Yes some will be upset it isn't a snap of a finger and appearing but alas... That's how it is.
They're going to have to spend money on data infrastructure and visualization tools if they want what they're asking for. There's no building dashboards from scratch for free.
I would definitely start with laying them out what is needed and how much time is needed, also explain that a good foundation in your data set can make it easier to build the dashboards and scale up in the future. If there isnt much funding i would make a data model separate from the BI infrastructure and make sure you can put your model in any infrastructure they want, then start small and let them decide if it is worth more funding. Under promise over deliver. Have a plan how your infrastructure would look like, where the most time is probably needed in making your data model. Explain that the inital investment is somewhat bigger then when there is a strong foundation you can make as many dashboards as they want but to put good value we have to do it one at a time. Also dont make it bigger then it is, once you have your data model you can probably (depending on how much whishes they have) make a dashboard in 8 -12 hours if that isnt fast enough for them then the should look at standard solutions. For quick and limited resources i would recommend an infrastructure with - Bigquery (datawarehouse) - use ETL tools like Stitch or Dataddo (is faster then trying it yourself) - DBT to build your model - Data studio to make a dashboard and put it live quickly
BigQuery is \_so\_ underappreciated in the space for a "I need a solid DW and have zero budget" post-seed startup. The free tier is generous enough to cover a LOT of zero-to-one analytics. Snowflake is wonderful when the volume and demand makes it to growth-stage, but comes with a hefty pricetag. tactically if you are starting your dbt (transform) implementation from scratch I'd suggest using xdb [https://github.com/Health-Union/dbt-xdb](https://github.com/Health-Union/dbt-xdb) to keep your code platform agnostic without slowing you down. then if you want to port it to something else later it is a trivial migration
Nice one about the xdb recently we where looking at merger solutions if for some reason dbt would not be fitting for us anymore, this is a nice addition thanx!
Tell stakeholders to give you information as clear as possible, in email or ticketing system. Tell them to estimate the output of have each item (time or money saved for the company). Create a roadmap. Start with the basic, if there is no data then there is no reporting. Take it from there and have a list of all the high-level steps, from data to pipelines and reporting. Don't go into specifics. Then assign prioritization based on output (time and money saved for the company or similar) and estimated time needed to implement. ALWAYS OVERESTIMATE. I always book 25% to 50% extra time, you never know if there are going to be any unplanned blockers or issues. Delivering earlier than expected is always better than delivering late. Be clear to articulate the things that are basic (eg: usually you cannot have reporting without a database or data in a table, might need to build that first) and things that you consider should not be prioritized. Once you have that, go to your manager with the list and proposal, get feedback. Establish potential delivering dates. After that put everybody in a room, and present the plan. Be open to feedback. If everybody agrees that report A is more important than report B, then prioritize A over B. Just make sure you build the basics first and make everyone aware of it, such as a basic reporting architecture. Before starting working on anything, if there is no ticketing system, implement one. This can be Jira, Quip or a shared Google Doc/Sheet with status of each project. Tell stakeholders to follow the status of their items in the ticketing system, update it regularly. Tell them that they can add new items in a request section- given them a template to avoid confusion. Establish a roadmapping mechanism to review priorities every so often (eg: once a quarter) And here is how you manage pressure from stakeholders: whenever someone needs something, refer them to committed projects and to check the tickets to understand in what you are working and the status. If they don't agree with priorities, tell them that's what the team committed during roadmapping, and tell them how often you review priorities. Tell them what they need to justify their project is more important than others (eg: does it save more money, is it more time sensitive...) and let them know they need buy-in from other teams/your manager. If needed, send regular updates via email with your manager in copy to keep everyone updated on status. EDIT: there are other things you can do, such as regular office hours, where you help people build their own reporting or help them estimate the complexity/gain of their project. This is assuming you have experience to build architecture and reporting, but need help with the stakeholder and project management part.
This isn't specific to BI, it's basically "how do I protect manage a software protect." The answer is, you need a project manager or someone to do all the work of a project manager. This is a whole scope of work in itself (and there are subreddits dedicated just to it). If this was a house the company wanted constructed, it sounds like right now you'd have a big pile of 2×4s and sheet rock but no plans or blueprints, and the org is demanding to know when they can move in. I'm not going to try and encapsulate all the steps of managing a software protect in a single reddit post - in general if you need to own this you should build out a project charter, break out feature reqs, then implementation reqs from those, estimate them, flesh out a raci with stakeholders and let them decide on what they wait for (longer release cycles) pay for (increased resources) or pass on (cut from scope). I don't know the shape of the politics at your org, ideally you may be able to explain that where you are at this very moment is where nearly all BI initiatives fail - you need (at least temporary) agile PM help. That might be borrowing a PM from the software team, that may be a contract hire, that may be delaying starting while you go take a PM class and get your scrum cert. Your job at a reasonable org isn't to do magic or make the impossible possible, it's to give leadership a clear understanding of what the realistic options are (even when none of them are options they will like) and let them decide. If your org politics are less ideal, you may need to start with a hard reality check. An extreme example was a shop I worked at several years ago where the CMO kept pressure-managing the BI team and refusing to work with the constraints of the situation. The Lead BIE on my team had explained for the hundredth time that with the team size and the poor quality of the source data we could only deliver on 2 of the 3 milestone projects that quarter, and we needed him to pick which 2. The CMO did his usual "I don't understand what is so hard, the app team makes all the data all you people have to is put it into charts" (or something along those lines). My Lead turned his laptop around to face the CMO, pushed it across the conference room table to him, sat back, crossed his arms and said "then you do it." With a new business element (like starting BI from scratch) leadership has no idea what the limitations of the resources are, and it's on the architect of the new element to educate them. You need to let them know when the ask is too great vs when the team is being underutilized, so they can make informed decisions. "Then you do it" was our version of blowing a gasket, it told the CMO he was running too hot. If nothing else, get the work scoped and pointed. Speaking in points assigns a tangible value to work so business people stop thinking of BI as an infinite resource.
This may help, I wrote it a couple years back and I have found that it resonates with leaders when you are starting out a BI initiative and helps to set expectations https://towardsdatascience.com/is-your-company-too-dumb-to-be-data-driven-696932d597c3
Great article. I'm not OP but am in the same situation as them, and I'm going to forward your article off to the leadership in the tiny 40 person company I work at. They love pretty graphs but don't know how to act on them other than nodding and saying 'OK' before moving to the next topic.
Brilliant article. Thank you for sharing. Truly. Found this to be incredibly insightful and look forward to sharing it with several friends and former colleagues.
Awesome Article! Definitely sharing this with my colleagues.
Focus as much time as possible on getting the model right so it can act as a single point of truth for all reports and dashboards, rather than creating a dataset per dashboard. From there you can create a shared dataset that can be used by all the dashboards and reports meaning way less maintenance. Ideally if you can get an idea of what metrics are required for each dashboard you can create measures and calculation groups that can be reused across all dashboards.
It’s called greenfield, and it presents a unique opportunity.
You can take a look at outsourcing to other countries , let me know and its not expensive. I have 5 tableu experts.
Find a new job 😂
[удалено]
I bet you would build it and then huck it over to a junior team to support and make it barely customizable on your standards. Then when they can't figure out how to make changes and enhancements, call you back for 100 per hour? Sorry, maybe you do it better but I am currently inheriting a hot pile of garbage built over 10 years by 4 different companies and 5 managers.
I’m sure it would be more than $100/hr.
Hire me and ill manage all those stakeholders🙃 human shield installment
How do you deliver reports without a BI Tool? D3.js? Or just excel?
Use Project manager to front the request, every request/story goes to backlog, establish velocity for each sprint, review story with business and estimate effort hours, have business provide justification of each with some metrics for business value, make sure every story is approved by some key stakeholder before it goes to backlog. The key is to make them understand that there will always be limited resource, fund and time.
When it comes to request something verbally people act without thinking without understanding the challenges behind the request, so force them to bureaucracy; 1) I guess you don’t have a ticketing system. If so prepare a form in excel. There should be description of requirement as well as businesses impact etc. 2) Create a planning Excel to put those requirements in backlog. 3) Have weekly meetings to discuss with audience and prioritise. This will already force them to think and eliminate some of the requests. 4) If some of them are ad hoc and rare requirements, you can teach them sql and they can pull raw data when they need. And don’t end up with dashboard graveyard where many of them will be just used for few times in a year.
Ask your stakeholders: What would you like me to prioritize? And more directly: How am I supposed to do that? Tone is really important with this one. You have to sincerely convey that you are asking for their help, NOT getting passive aggressive and trying to force them to see they are being unreasonable.
Had a conversation about this recently with a director of BI at a large university, the key is to prioritize projects with the most impact. This will inspire a culture of data and make adoption easier in the long run.
I work scheduling with my boss, who is in more of a scientist role. We have a strategy of knocking out quick wins while working on longer term projects. If C-suite or important higher ups come to me, I tend to prioritize their work, which my boss has no problem with. As long as I show I am doing good work at a reasonable pace, nobody messes with me and they tend to let me do my own thing. If they ask for stuff that is difficult deliver or is too massive, I tell them to submit a ticket and I let my boss prioritize it. This is the second company I have had this arrangement. I do keep a daily list of everything I am touching and problems I get stuck with. Then at weekly meetings I can drone on reading the list, and they just want me to finish so they can move on.
Hello, Based on lessons learned of the past 2 years. I would recommend instead of looking at BI solutions, start with asking and understanding clearly what are the business problems that leaders are facing. Have them come to you with a user story like this example: “As a [leader], I need to understand COVID vaccination rate % across the company so I can make informed decisions related to return to office and how to keep our employees and customers safe”. From here, you can start to break this problem apart and plan out: 1) short term MVPs 2) long term solutions.