I agree with everything you said. However, even if one were to implement all that, they'll still be dealing with some ad-hoc requests.
For the simpler ones ("can you just pull"), there will be AI. I know it feels like it's not trustworthy/precise yet, but it will get there. For the basic stuff, for sure.
Depends how you see the approach. When you generate everything out with genai even modelling then you give the tools and the business chooses the end result with support. You are partner of the business and never behind.
Really appreciated this one, especially the distinction between serving the stakeholder versus serving the business. It’s a subtle shift but it completely changes how you prioritize and communicate as a data team.
The part about thinking one level up also hit home. A lot of times we stop at delivering the what, when understanding the why and who it's for is what actually creates impact.
"Start asking not only what your boss wants, but why. What’s the end use? Who are they trying to influence? In many cases, that dashboard or report isn’t for internal analysis. It’s going straight to an executive update or board deck. Sometimes, they just need a sound bite to impress the C-suite.
So ask!
“Who’s this for?”
“How will this be used?”
“What are they trying to decide or prove?”"
Hi Ben,
I disagree. The IT people delivering the data warehouse have no place asking such questions. They should be focussed on putting all the data that may possibly be useful one day into the data warehouse.
It is up to the business people to decide what questions they want to ask and to get their own answers initially. Only when important questions have been answered and the answer was valuable and then needs to be provided repeatedly for tracking purposes should it go into any sort of report or dashboard.
Let me explain.
Metaphor Computer Systems had a methodology that had a suite of questions in it that the business analysts at Meta5 asked the most senior people in their customers. A highly evolved version of that methodology, with these and many more questions, is freely available in my methodology.
The people interviewing the senior management team from the customer back in the Metaphor days were not IT people. They were business people. And they defined what was to be put into the then dimensional data warehouses because of the expense of disk and ETL development in those days.
IT people should never be doing that job of interviewing the senior management to figure out how to support the business with a data warehouse. If you let IT people do those interviews the percentage likely failure goes up dramatically.
I was given a copy of this methodology in 1993 and told how it worked. I didn't get any training on it. My problem was I was an IBM Systems Engineer and my IBM customers saw me as a "techinical person". Even so men like the head of marketing for Johnson and Johnson in Australia / New Zealand hired me to solve problems no one at Johnson and Johnson could.
As I learned in those early days I realised that I had to make the transition to be trusted and respected by the business side of the house if I was going to be able to sell the multi-million dollar deals I wanted to sell.
So I worked very hard on my business side skills, knowledge and understanding. Little by little the business side of the house slowly accepted me by 1997. I sold my first two multi-million dollar deals in 1997 and in one of them I did the interviews with the 12-15 most senior people in the company. Those two were pretty much my breakthrough deals.
Technology people rarely bother to put in the sort of time and effort I put in from 1993-1997 to master the business side of the house skills. And without those skills and that knowledge? They are not respected on the business side of the house and nor should they be in my humble opinion.
So, in my experience, from 1997, I used to make the sale and then do the senior management team interviews, help prepared the prototypes and once the prototypes were approved for development the team went ahead and built what the prototypes proved.
Bill, Ralph, myself, and others who were experienced in this area tried to tell IT people this is what they should be doing in the second half of the 90s. But IT people didn't listen and our industry snatched defeat from the Jaws of victory.
By using that methodology we had great results in every client who took our advice. I have many public references for how that worked out. But the key point is this.
The person who interviews the senior management team must be a business person who has earned the respect of the business side of the house. If the person who interviews the senior management team is not that? The chances of success are less than 50%.
I have a blog post about Qantas, our Australian Airline. I did the cargo division in 2000. The short story is that I did the interviews of the 15 or so most senior business managers. They then complained to the Managing Director about me and told him I was not asking the questions they expected in the interviews. I was 36 in 2000.
The MD called me into his office to ask my opinion on these complaints and I told him they were normal and to be expected. I told him that I did things differently because I was the best in the country at what I do. And I do not do the same style of interviews as others because others fail. I don't. This project had failed three times before and the senior managers were expecting me to ask the same sorts of questions as the failed projects.
The MD was very amused at my confidence being such a young man who had never worked in this segment before but he said go ahead and lets see how I do.
When I did the demo of the prototype 6 weeks later that same MD asked me this question. He said "I know you have never worked in our segment before, but what you just showed me is exactly what we need and you presented in such a way that I would be impressed if you had worked here for 10 years. How did you do that?"
I reminded him that 6 weeks earlier he had me in his office asking about the complaints of many of the people in this room and I told him I was the best in the country at this....and that is how I did it. He simply nodded and said "You did indeed tell me that and now I believe you." All those who had complained about me laughed kind of nervously.
At the end of the day, the methodology Metaphor invented and I "stole" and further developed focuses on finding out about the business and the value drivers of the business. We don't even talk about data in such interviews. Then what we do is build the data warehouse with everything in it and we then figure out how to drive new profit out of the business using the data warehouse to figure that out.
In one of my most famous reference accounts I did the largest magazine publisher in Australia owned by the countries richest man, Kerry Packer. I did that in 2000 as well. The company had been going down hill for 5 years and Kerry Packer called it "a dog with fleas". I built the "take everything" data warehouse and two years later Kerry Packer called it "The Jewel in the Corporate Crown" because we had increased market share from 37% to 42% and doubled gross profit.
The vast majority of that profit came from one idea and it wasn't even my idea. We got the idea from our first business workshop with all the senior managers. One of their senior people had had this thought in her head for years and it could not be tested. So she told us about her idea at the very first meeting we had and we took notes and it went into the notes. When the data warehouse was built we tested her idea, she was right, and that was worth over $A100 million per year in new profit. Not bad.
In fact the ACP project paid for itself before we even got into production, the fastest payback I have ever had.
Bill, Ralph, myself, and others tried really hard to educate people in our industry how to sustainably increase profit in large companies all through the late 90s. In late 2002 I gave up and just went on my way selling data models and installing them. Our whole industry has not done very well since then.
Great stuff - and thanks for the spotlight on contributors like Celina (great quote, strategy is what you say no to). Context, business purpose, audience, those are all things I've used to shape (rather than say no) the direction of the request. Not to mention moving to a gpt experience with analytics - prompts help reduce the noise and clarify the context.
Depending on the functiuonal maturity level of the organization, there are some methodologies which need to be in place and well understood to avoid being the ticket processor for reporting.
First - the organization needs to understand what it is measuring and why. As a part of that, it needs to know who is doing that measurment and if the measures are static or need interpretation or consistent refinement. Example: in a tier 2 or 3 maturity organization, new features almost universially have 10x to 50x too many metrics. We build these dashboards for a feature, and six weeks later - we end up only using one or two metrics and periodically at that. Many times organizations make the very costly mistake to materialize all these metrics in a data warehouse or lake house - don't. Wait to make the decision about *what* to persist and materialize until enough is known about the data and business function. Failure to implement this methodology leads to extremely costly and inefficient data systems long term.
Its a good thing that an organization includes measurement of features in rollout - but it should also recognize it does not know enough until the feature gets usage to know. The obvious route there is for the implementors to measure by hand until there is a pattern and the stakeholders agree to persist a permanent metric and solution with all the sunk costs of documentation and implementation semantics - instead of creating a maintenance burden going forward.
This concept of being efficient overall is very, very important to stay agile over the long run.
Second - this is not the same thing as knowledge generation. Many questions need to be answered, and need indepth analysis, research - and more. This is the reason we have analytics departments. What is important and difficult: how to confirm and then propogate the results. It does zero good to an organiztation if the knowledge is not shared so everyone can have a common understanding. To have that common understanding of complex data - vastly accelerates decision making and brings crowd-sourced solutions to the forefront - because there is simply so much less to discuss and argue about.
Third - this all leads down the path of knowing which actor needs to do the work. Is it the developer? The data engineer? The Analyist - the Executive? Which is a complex task requiring several organizational maturity things to be in place and well understood. A stakeholder committee is an example... if for no other reason than being able to reach consensus quicky.
"How do you shift your data team from reactive responders to strategic partners?"
Ben,
Ralph Kimball, Bill Inmon and others figured this out in the late 80s and early 90s. I went to the September 1993 Metaphor Users Conference and saw this up close and personal. I talked to the leaders of the Metaphor projects at places like Coca Cola, Procter and Gamble, Wall Greens, Better Homes and Gardens. All those sorts of people.
Just so you know. The head of Coca Cola BI Worldwide invited Bill Inmon to give the key note speech at that conference. I was having lunch at his table the day before and he told everyone at the table to make sure they got front row seats for Bills presentation.
The two main messages were this.
1. Prepare to put ALL your data into your data warehouse in the future. We couldn't do it in 1993 but this is exactly what Bill was talking about. When Bill was talking about this we could not even fathom an attempt to put ALL operational data into the data warehouse because it was so hard to get ANY data into the data warehouse in 1993.
2. IT people have no place doing queries or writing reports. That is the domain of the business people. There was actually one Metaphor customer who gave a presentation about how much they were controlling the availability of information. The next speak was from Better Homes and Gardens. His first comment was "I am fred smith and I run all informational processing at Better Homes and Gardens, I have an MBA, not an IT degree. We fired everyone in our company who kept our data from us and we query our own data now. We own the data. Not IT. There were cheers from the 50 or so people in the room. LOL!
Of course, over the last 30 years we have improved things. We can now map 15,000+ fields per month from large operational systems to the target data warehouse. That means any company can now afford to put ALL their data into the data warehouse that should be there.
The role of IT is to make sure the data is up to date, correct, audited, balanced etc. IT needs to make sure the models are dimensional and multi-level. And IT can monitor the queries being asked to add summaries to improve speed and reduce costs. That's it.
The 5 smartest people in the business can be given a copy of the software that Ralph helped design and you can leave them to it. IT should not be answering any "one off questions". IT should not be "constantly adding data to the data warehouse" because it should have all been done in Version 1.0.
IT should only be adding new data from new tables and new columns in the operational systems and new external data to the data warehouse.
I, personally, did my first "map everything" project in 1997 and that's what I have done ever since.
Unfortunately IBM screwed up Ralphs product but it is available now on windows at www.meta5.com.
I have promoted what is now Meta5 for 34 years. I will keep promoting it because it is the best product to answer the "just thought of question" and that is where the money is.
I agree with everything you said. However, even if one were to implement all that, they'll still be dealing with some ad-hoc requests.
For the simpler ones ("can you just pull"), there will be AI. I know it feels like it's not trustworthy/precise yet, but it will get there. For the basic stuff, for sure.
Depends how you see the approach. When you generate everything out with genai even modelling then you give the tools and the business chooses the end result with support. You are partner of the business and never behind.
Really appreciated this one, especially the distinction between serving the stakeholder versus serving the business. It’s a subtle shift but it completely changes how you prioritize and communicate as a data team.
The part about thinking one level up also hit home. A lot of times we stop at delivering the what, when understanding the why and who it's for is what actually creates impact.
"Start asking not only what your boss wants, but why. What’s the end use? Who are they trying to influence? In many cases, that dashboard or report isn’t for internal analysis. It’s going straight to an executive update or board deck. Sometimes, they just need a sound bite to impress the C-suite.
So ask!
“Who’s this for?”
“How will this be used?”
“What are they trying to decide or prove?”"
Hi Ben,
I disagree. The IT people delivering the data warehouse have no place asking such questions. They should be focussed on putting all the data that may possibly be useful one day into the data warehouse.
It is up to the business people to decide what questions they want to ask and to get their own answers initially. Only when important questions have been answered and the answer was valuable and then needs to be provided repeatedly for tracking purposes should it go into any sort of report or dashboard.
Let me explain.
Metaphor Computer Systems had a methodology that had a suite of questions in it that the business analysts at Meta5 asked the most senior people in their customers. A highly evolved version of that methodology, with these and many more questions, is freely available in my methodology.
The people interviewing the senior management team from the customer back in the Metaphor days were not IT people. They were business people. And they defined what was to be put into the then dimensional data warehouses because of the expense of disk and ETL development in those days.
IT people should never be doing that job of interviewing the senior management to figure out how to support the business with a data warehouse. If you let IT people do those interviews the percentage likely failure goes up dramatically.
I was given a copy of this methodology in 1993 and told how it worked. I didn't get any training on it. My problem was I was an IBM Systems Engineer and my IBM customers saw me as a "techinical person". Even so men like the head of marketing for Johnson and Johnson in Australia / New Zealand hired me to solve problems no one at Johnson and Johnson could.
As I learned in those early days I realised that I had to make the transition to be trusted and respected by the business side of the house if I was going to be able to sell the multi-million dollar deals I wanted to sell.
So I worked very hard on my business side skills, knowledge and understanding. Little by little the business side of the house slowly accepted me by 1997. I sold my first two multi-million dollar deals in 1997 and in one of them I did the interviews with the 12-15 most senior people in the company. Those two were pretty much my breakthrough deals.
Technology people rarely bother to put in the sort of time and effort I put in from 1993-1997 to master the business side of the house skills. And without those skills and that knowledge? They are not respected on the business side of the house and nor should they be in my humble opinion.
So, in my experience, from 1997, I used to make the sale and then do the senior management team interviews, help prepared the prototypes and once the prototypes were approved for development the team went ahead and built what the prototypes proved.
Bill, Ralph, myself, and others who were experienced in this area tried to tell IT people this is what they should be doing in the second half of the 90s. But IT people didn't listen and our industry snatched defeat from the Jaws of victory.
By using that methodology we had great results in every client who took our advice. I have many public references for how that worked out. But the key point is this.
The person who interviews the senior management team must be a business person who has earned the respect of the business side of the house. If the person who interviews the senior management team is not that? The chances of success are less than 50%.
I have a blog post about Qantas, our Australian Airline. I did the cargo division in 2000. The short story is that I did the interviews of the 15 or so most senior business managers. They then complained to the Managing Director about me and told him I was not asking the questions they expected in the interviews. I was 36 in 2000.
The MD called me into his office to ask my opinion on these complaints and I told him they were normal and to be expected. I told him that I did things differently because I was the best in the country at what I do. And I do not do the same style of interviews as others because others fail. I don't. This project had failed three times before and the senior managers were expecting me to ask the same sorts of questions as the failed projects.
The MD was very amused at my confidence being such a young man who had never worked in this segment before but he said go ahead and lets see how I do.
When I did the demo of the prototype 6 weeks later that same MD asked me this question. He said "I know you have never worked in our segment before, but what you just showed me is exactly what we need and you presented in such a way that I would be impressed if you had worked here for 10 years. How did you do that?"
I reminded him that 6 weeks earlier he had me in his office asking about the complaints of many of the people in this room and I told him I was the best in the country at this....and that is how I did it. He simply nodded and said "You did indeed tell me that and now I believe you." All those who had complained about me laughed kind of nervously.
At the end of the day, the methodology Metaphor invented and I "stole" and further developed focuses on finding out about the business and the value drivers of the business. We don't even talk about data in such interviews. Then what we do is build the data warehouse with everything in it and we then figure out how to drive new profit out of the business using the data warehouse to figure that out.
In one of my most famous reference accounts I did the largest magazine publisher in Australia owned by the countries richest man, Kerry Packer. I did that in 2000 as well. The company had been going down hill for 5 years and Kerry Packer called it "a dog with fleas". I built the "take everything" data warehouse and two years later Kerry Packer called it "The Jewel in the Corporate Crown" because we had increased market share from 37% to 42% and doubled gross profit.
The vast majority of that profit came from one idea and it wasn't even my idea. We got the idea from our first business workshop with all the senior managers. One of their senior people had had this thought in her head for years and it could not be tested. So she told us about her idea at the very first meeting we had and we took notes and it went into the notes. When the data warehouse was built we tested her idea, she was right, and that was worth over $A100 million per year in new profit. Not bad.
In fact the ACP project paid for itself before we even got into production, the fastest payback I have ever had.
Bill, Ralph, myself, and others tried really hard to educate people in our industry how to sustainably increase profit in large companies all through the late 90s. In late 2002 I gave up and just went on my way selling data models and installing them. Our whole industry has not done very well since then.
Great stuff - and thanks for the spotlight on contributors like Celina (great quote, strategy is what you say no to). Context, business purpose, audience, those are all things I've used to shape (rather than say no) the direction of the request. Not to mention moving to a gpt experience with analytics - prompts help reduce the noise and clarify the context.
Depending on the functiuonal maturity level of the organization, there are some methodologies which need to be in place and well understood to avoid being the ticket processor for reporting.
First - the organization needs to understand what it is measuring and why. As a part of that, it needs to know who is doing that measurment and if the measures are static or need interpretation or consistent refinement. Example: in a tier 2 or 3 maturity organization, new features almost universially have 10x to 50x too many metrics. We build these dashboards for a feature, and six weeks later - we end up only using one or two metrics and periodically at that. Many times organizations make the very costly mistake to materialize all these metrics in a data warehouse or lake house - don't. Wait to make the decision about *what* to persist and materialize until enough is known about the data and business function. Failure to implement this methodology leads to extremely costly and inefficient data systems long term.
Its a good thing that an organization includes measurement of features in rollout - but it should also recognize it does not know enough until the feature gets usage to know. The obvious route there is for the implementors to measure by hand until there is a pattern and the stakeholders agree to persist a permanent metric and solution with all the sunk costs of documentation and implementation semantics - instead of creating a maintenance burden going forward.
This concept of being efficient overall is very, very important to stay agile over the long run.
Second - this is not the same thing as knowledge generation. Many questions need to be answered, and need indepth analysis, research - and more. This is the reason we have analytics departments. What is important and difficult: how to confirm and then propogate the results. It does zero good to an organiztation if the knowledge is not shared so everyone can have a common understanding. To have that common understanding of complex data - vastly accelerates decision making and brings crowd-sourced solutions to the forefront - because there is simply so much less to discuss and argue about.
Third - this all leads down the path of knowing which actor needs to do the work. Is it the developer? The data engineer? The Analyist - the Executive? Which is a complex task requiring several organizational maturity things to be in place and well understood. A stakeholder committee is an example... if for no other reason than being able to reach consensus quicky.
Its all a sticky subject.
"So how do you break the cycle?"
"How do you shift your data team from reactive responders to strategic partners?"
Ben,
Ralph Kimball, Bill Inmon and others figured this out in the late 80s and early 90s. I went to the September 1993 Metaphor Users Conference and saw this up close and personal. I talked to the leaders of the Metaphor projects at places like Coca Cola, Procter and Gamble, Wall Greens, Better Homes and Gardens. All those sorts of people.
Just so you know. The head of Coca Cola BI Worldwide invited Bill Inmon to give the key note speech at that conference. I was having lunch at his table the day before and he told everyone at the table to make sure they got front row seats for Bills presentation.
The two main messages were this.
1. Prepare to put ALL your data into your data warehouse in the future. We couldn't do it in 1993 but this is exactly what Bill was talking about. When Bill was talking about this we could not even fathom an attempt to put ALL operational data into the data warehouse because it was so hard to get ANY data into the data warehouse in 1993.
2. IT people have no place doing queries or writing reports. That is the domain of the business people. There was actually one Metaphor customer who gave a presentation about how much they were controlling the availability of information. The next speak was from Better Homes and Gardens. His first comment was "I am fred smith and I run all informational processing at Better Homes and Gardens, I have an MBA, not an IT degree. We fired everyone in our company who kept our data from us and we query our own data now. We own the data. Not IT. There were cheers from the 50 or so people in the room. LOL!
Of course, over the last 30 years we have improved things. We can now map 15,000+ fields per month from large operational systems to the target data warehouse. That means any company can now afford to put ALL their data into the data warehouse that should be there.
The role of IT is to make sure the data is up to date, correct, audited, balanced etc. IT needs to make sure the models are dimensional and multi-level. And IT can monitor the queries being asked to add summaries to improve speed and reduce costs. That's it.
The 5 smartest people in the business can be given a copy of the software that Ralph helped design and you can leave them to it. IT should not be answering any "one off questions". IT should not be "constantly adding data to the data warehouse" because it should have all been done in Version 1.0.
IT should only be adding new data from new tables and new columns in the operational systems and new external data to the data warehouse.
I, personally, did my first "map everything" project in 1997 and that's what I have done ever since.
Unfortunately IBM screwed up Ralphs product but it is available now on windows at www.meta5.com.
I have promoted what is now Meta5 for 34 years. I will keep promoting it because it is the best product to answer the "just thought of question" and that is where the money is.
Ok?