When the LTV project was rolled out and data was being published I immediately found myself with two new tasks: educating the company about the LTV project and explaining why particular customers got negative value.
I anticipate that education will be part of any analytic project. The most important decision we made about education was to explain everything. There was no part of the LTV system that we did not discuss and even give specific parameters for. Explaining everything allowed people to understand the LTV system.
What really made people accept the LTV system was being able to answer why particular customers had negative scores. In particular we got a number of calls from Customer Care. LTV had been integrated into the Customer Care system and it effected what kind of equipment offers could be made to customers. The Customer Care department needed to know why some high-revenue customers were getting low or negative value.
We were able to answer questions like this easily and convincingly. As it turned out, the usual reason high revenue customers had negative LTV was because they hadn't actually paid their bill in a number of months. Being able to answer these questions went a long way to establishing our credibility.
Showing posts with label business intelligence. Show all posts
Showing posts with label business intelligence. Show all posts
Wednesday, April 16, 2008
LTV at LTC: Building the System
Building the LTV system took a small team approximately two months out of a year spent on the project, from building the lifetime models to coding the formulas to finally building a system of monthly HTML reports. Ironically actually building the LTV project was the simplest part of the whole project.
Monday, April 14, 2008
LTV at LTC: Alarms and Diversions; the New Media Department (NMD)
In LTC, we had a department dedicated to exploring new technologies and new media applications. The technology to really make NMD's projects really go wasn't slated to go live until the year after the LTV project, but they were still very interested in the LTV project. Their interest culminated in a meeting that nearly ended the LTV project.
NMD had segmented the customer base, and had identified the segment they wanted to market to. NMD was horrified that one of their potential customers might get a poor score, and so perhaps not get the best possible service. Never mind the equal possibility that their potential customers might get good scores and receive preferential treatment – NMD was terrified at the possibility of anything bad possibly happening to their potential base. The most vivid quote of the meeting was “We have to stop this!”
If NMD really tried to stop the LTV project, I am fairly sure that we could have overcome their resistance but I'm certain that if the meeting ended there we would have a lot of unnecessary turmoil. What I did was I put back on my Project Designer hat and let NMD specify a value formula just for them that would identify the customers NMD most wanted. This approach was successful because I was able to promise right then and there that NMD could design the formula the way NMD wanted and that it would be published along with the other LTV scores.
In a typical project situation there would have been an initial meeting with NMD, their concerns would have been taken back the the larger group, possible solutions discussed, project forms filled out and signed off on, and all this over a course of several weeks. During these weeks NMD would have solidified their position and the LTV project would have been threatened by a protracted political fight that would weaken the project at best and conceivably stop the project all together.
NMD had segmented the customer base, and had identified the segment they wanted to market to. NMD was horrified that one of their potential customers might get a poor score, and so perhaps not get the best possible service. Never mind the equal possibility that their potential customers might get good scores and receive preferential treatment – NMD was terrified at the possibility of anything bad possibly happening to their potential base. The most vivid quote of the meeting was “We have to stop this!”
If NMD really tried to stop the LTV project, I am fairly sure that we could have overcome their resistance but I'm certain that if the meeting ended there we would have a lot of unnecessary turmoil. What I did was I put back on my Project Designer hat and let NMD specify a value formula just for them that would identify the customers NMD most wanted. This approach was successful because I was able to promise right then and there that NMD could design the formula the way NMD wanted and that it would be published along with the other LTV scores.
In a typical project situation there would have been an initial meeting with NMD, their concerns would have been taken back the the larger group, possible solutions discussed, project forms filled out and signed off on, and all this over a course of several weeks. During these weeks NMD would have solidified their position and the LTV project would have been threatened by a protracted political fight that would weaken the project at best and conceivably stop the project all together.
Sunday, April 13, 2008
Effective vs. Efficient Teams
There's a difference between 'effectiveness' and 'efficiency'
An organization is efficient when each person knows their job, does their job, and there is no slack in the organization. Every person knows exactly what they need to. No less and no more.
This is typically what enterprises drive for: efficient organizations. Typically there will be a communication layer that has minimal understanding of technical details in general and almost no understanding of the technical details in the enterprise. This layer will then communicate to the technical teams, that have almost no knowledge of the business details of the enterprise. The technical teams are actively discouraged from having contact with anyone in the enterprise aside from their designated contacts in the communication layer.
An extreme case is the production team. Every one on that team has a very precise job description and come what may they do not want to deviate from that job description. Each member of the team knows only what is necessary in order to do their job, and quite intentionally does not have any knowledge beyond that.
An efficient team like this is almost completely ineffective at doing anything new. To start with, they have no time. Moreover, no one on an efficient team has the kind of overview necessary to tackle a project that is at all innovative. Depressingly, "something new" can be "getting the data right". If a field may or may not have correct data, then it requires a great deal of research to verify the problem, identify the true problem, and fix the problem. If the data problem does not prevent any of the efficient team's scripts from running, then the efficient team won't care very much one way or another about the data being right or wrong. They can do their job the way they were told, and by the design of the team that is all they care about. More than once and at more than one company I've had a production team simply refuse to fix data problems in their systems.
An effective team should have members that have specialties but each can engage on every other person's areas. The managers and business contacts should be able to effective talk to and in a pinch do the technical aspects; the more technical people should have a good grounding in the overall enterprise and should be able to represent the effective team in meetings.
Effective teams often do not make good efficient teams. People that can be on effective teams are rare and valuable, and the grind of production work can easily grind on them. Enterprises need efficient teams to get the work done, but in budget pressures effective teams can often get pushed aside and that's a mistake.
An organization is efficient when each person knows their job, does their job, and there is no slack in the organization. Every person knows exactly what they need to. No less and no more.
This is typically what enterprises drive for: efficient organizations. Typically there will be a communication layer that has minimal understanding of technical details in general and almost no understanding of the technical details in the enterprise. This layer will then communicate to the technical teams, that have almost no knowledge of the business details of the enterprise. The technical teams are actively discouraged from having contact with anyone in the enterprise aside from their designated contacts in the communication layer.
An extreme case is the production team. Every one on that team has a very precise job description and come what may they do not want to deviate from that job description. Each member of the team knows only what is necessary in order to do their job, and quite intentionally does not have any knowledge beyond that.
An efficient team like this is almost completely ineffective at doing anything new. To start with, they have no time. Moreover, no one on an efficient team has the kind of overview necessary to tackle a project that is at all innovative. Depressingly, "something new" can be "getting the data right". If a field may or may not have correct data, then it requires a great deal of research to verify the problem, identify the true problem, and fix the problem. If the data problem does not prevent any of the efficient team's scripts from running, then the efficient team won't care very much one way or another about the data being right or wrong. They can do their job the way they were told, and by the design of the team that is all they care about. More than once and at more than one company I've had a production team simply refuse to fix data problems in their systems.
An effective team should have members that have specialties but each can engage on every other person's areas. The managers and business contacts should be able to effective talk to and in a pinch do the technical aspects; the more technical people should have a good grounding in the overall enterprise and should be able to represent the effective team in meetings.
Effective teams often do not make good efficient teams. People that can be on effective teams are rare and valuable, and the grind of production work can easily grind on them. Enterprises need efficient teams to get the work done, but in budget pressures effective teams can often get pushed aside and that's a mistake.
Friday, April 11, 2008
LTV at LTC: Difficult Allies
A particularly long and difficult set of meetings that we had was with the LTC Finance Group (FG).
These meetings were, of course, difficult. LTV projects by their nature are focused on customers and their value and that makes LTV projects in the Marketing Department's area; but LTV also involves financial impact and financial data and that makes it part of the Finance Department's area. I suspect that if there is an LTV project where Marketing and Finance are not arguing about the details then the project isn't being taken seriously by either department.
The FG was currently managing an LTV-like project and had been for a number of years. What FG did was to look at revenue and cost data and then give profitability data by rate plan. Profitability by rate plan really wasn't that useful to LTC. It gave no understanding of the 'why' behind customer value or how to treat individual customers.
We needed the FG for was to understand the cost metrics associated with customer activity. In particular, our executive sponsor insisted that we have FG's approval for out LTV project. We went to the FG with the question “What is the right formula to calculate customer related costs?” -- and they refused.
Well, they didn't refuse, exactly. What happened after that was a long series of meetings with various financial people, getting one small piece of data from each. Then came time to put all the pieces together and life started getting difficult.
The FG refused to either accept or reject our meeting requests, meaning we could never be sure if a meeting was actually on or not until we made the call. They would also invite themselves to other meetings, so we had to be ready to talk about LTV issues at any time. Our questions got answered obliquely. For instance, when we asked about the best way to handle network minutes the reply was “What would happen if all of our customers leave?”
As it developed, the FG and our group did develop a substantial difference of opinion in how to value customers. It revolved around how to handle capital expenses. The FG was adamant that any customer valuation include capital expense; I felt strongly that the customer LTV should not. I had two reasons. First, no future customer activity could effect capital projects that had already been purchased. LTV should be about customer impacts to LTC, not things that individual customers had little impact on. Second, including capital expenses would mean that 25% of the customers would have negative value; without capital expenses 7% of the customers would be have negative value.
Let me digress here on negative LTV. By and large, in any company there will be some customers that cost more in company resources than they bring in in revenue. One of the best goals of any LTV project is correctly identifying customers of negative value so they can be understood, targeted, addressed, and if necessary 'fired'. It is absolutely natural to take customers with negative LTV and take them out of customer retention programs.
Cutting 7% of the base out of marketing programs at LTC designed to increase retention would have minimal impact on the overall attrition results. Taking 25% of the customer base out of retention marketing programs would have a definite impact on the corporate retention efforts.
LTC lived and died by retention and attrition. If LTV hurt retention then LTV would be quickly and quietly abandoned.
We spent months in rounds of inconclusive meetings with FG, asking again and again about the correct formulation. Suddenly, they agreed with us and we could go forwards. As we found out later, their agreement was by accident. The FG simply misread the formula we were laying out and thought it included capital expenses. By the time the FG realized they had made a mistake the LTV system was already in production and going forwards.
There is a bit of an irony here. If the FG had simply worked with us and given us their cost formula we would have taken it uncritically and not done the research to discover the issues around capital expenses.
Despite our differences the two groups did come to an understanding and became allies on many issues. Both groups wanted to move LTC from gross revenue to sustainable profit. We both realized that two areas that LTC had ignored, off-net expenses1 and bad debt expenses, were critical to profitability.
These meetings were, of course, difficult. LTV projects by their nature are focused on customers and their value and that makes LTV projects in the Marketing Department's area; but LTV also involves financial impact and financial data and that makes it part of the Finance Department's area. I suspect that if there is an LTV project where Marketing and Finance are not arguing about the details then the project isn't being taken seriously by either department.
The FG was currently managing an LTV-like project and had been for a number of years. What FG did was to look at revenue and cost data and then give profitability data by rate plan. Profitability by rate plan really wasn't that useful to LTC. It gave no understanding of the 'why' behind customer value or how to treat individual customers.
We needed the FG for was to understand the cost metrics associated with customer activity. In particular, our executive sponsor insisted that we have FG's approval for out LTV project. We went to the FG with the question “What is the right formula to calculate customer related costs?” -- and they refused.
Well, they didn't refuse, exactly. What happened after that was a long series of meetings with various financial people, getting one small piece of data from each. Then came time to put all the pieces together and life started getting difficult.
The FG refused to either accept or reject our meeting requests, meaning we could never be sure if a meeting was actually on or not until we made the call. They would also invite themselves to other meetings, so we had to be ready to talk about LTV issues at any time. Our questions got answered obliquely. For instance, when we asked about the best way to handle network minutes the reply was “What would happen if all of our customers leave?”
As it developed, the FG and our group did develop a substantial difference of opinion in how to value customers. It revolved around how to handle capital expenses. The FG was adamant that any customer valuation include capital expense; I felt strongly that the customer LTV should not. I had two reasons. First, no future customer activity could effect capital projects that had already been purchased. LTV should be about customer impacts to LTC, not things that individual customers had little impact on. Second, including capital expenses would mean that 25% of the customers would have negative value; without capital expenses 7% of the customers would be have negative value.
Let me digress here on negative LTV. By and large, in any company there will be some customers that cost more in company resources than they bring in in revenue. One of the best goals of any LTV project is correctly identifying customers of negative value so they can be understood, targeted, addressed, and if necessary 'fired'. It is absolutely natural to take customers with negative LTV and take them out of customer retention programs.
Cutting 7% of the base out of marketing programs at LTC designed to increase retention would have minimal impact on the overall attrition results. Taking 25% of the customer base out of retention marketing programs would have a definite impact on the corporate retention efforts.
LTC lived and died by retention and attrition. If LTV hurt retention then LTV would be quickly and quietly abandoned.
We spent months in rounds of inconclusive meetings with FG, asking again and again about the correct formulation. Suddenly, they agreed with us and we could go forwards. As we found out later, their agreement was by accident. The FG simply misread the formula we were laying out and thought it included capital expenses. By the time the FG realized they had made a mistake the LTV system was already in production and going forwards.
There is a bit of an irony here. If the FG had simply worked with us and given us their cost formula we would have taken it uncritically and not done the research to discover the issues around capital expenses.
Despite our differences the two groups did come to an understanding and became allies on many issues. Both groups wanted to move LTC from gross revenue to sustainable profit. We both realized that two areas that LTC had ignored, off-net expenses1 and bad debt expenses, were critical to profitability.
Wednesday, April 9, 2008
LTV at LTC: The New Economy Consulting Company (NECC)
One lengthly set of meetings that did work out very well as with the New Economy Consulting Company (NECC), a company that started out specializing in Internet marketing but by 2002 had branched out into general customer relationship management consulting.
NECC was leading their own LTV project which ultimately got nowhere but our project was able to use many of their insights.
NECC had realized that LTV comes in four flavors:
Usually, when we think of LTV we think of just (1). At LTC all four metrics were very useful.
LTC had a very large customer acquisition cost; it often took a year for a customer to pay of their acquisition cost. By tracking a customer's past and future values separately we were able to see the full impact of different acquisition strategies.
LTC's direct marketing concentrated on retention efforts, and the difference between Expected Future Value and Potential Future Value became the natural metric to run attrition campaigns against (i.e., if a customer's EFV was $250, and PFV was $475, then $475 - $250 = $225; if we plan on recovering 10% of the difference between EFV and PFV then for that customer we shouldn't spend more that $22.50 to do so).
The NECC project never got beyond PowerPoint because they had made no plans for implementation. Once the report was complete the project faded away.
Moreover, NECC never really dove into the financials of LTC. What they did was to go around asking people what they thought was important and put together the subjective, narrow opinions. A project like LTV is a rare chance to look at a problem holistically and completely and the chance to bring new understanding to the enterprise as a whole should not be missed.
NECC was leading their own LTV project which ultimately got nowhere but our project was able to use many of their insights.
NECC had realized that LTV comes in four flavors:
- Expected Future Value
- Total Past Value
- Potential Future Value: What would the customer be worth is there was no churn?
- Expected Life Value: (1) + (2)
Usually, when we think of LTV we think of just (1). At LTC all four metrics were very useful.
LTC had a very large customer acquisition cost; it often took a year for a customer to pay of their acquisition cost. By tracking a customer's past and future values separately we were able to see the full impact of different acquisition strategies.
LTC's direct marketing concentrated on retention efforts, and the difference between Expected Future Value and Potential Future Value became the natural metric to run attrition campaigns against (i.e., if a customer's EFV was $250, and PFV was $475, then $475 - $250 = $225; if we plan on recovering 10% of the difference between EFV and PFV then for that customer we shouldn't spend more that $22.50 to do so).
The NECC project never got beyond PowerPoint because they had made no plans for implementation. Once the report was complete the project faded away.
Moreover, NECC never really dove into the financials of LTC. What they did was to go around asking people what they thought was important and put together the subjective, narrow opinions. A project like LTV is a rare chance to look at a problem holistically and completely and the chance to bring new understanding to the enterprise as a whole should not be missed.
Tuesday, April 8, 2008
LTV at LTC: First, Meetings
Of course once we got approval we didn't start building the system. We started having meetings about building the system.
The first set of planned meetings didn't actually happen, which was a very good thing. Our manager wanted us hold bi-weekly meetings with managers from across the marketing organization. These meetings would have been a disaster.
We didn't know enough about LTV in general and customer behavior at LTC in specific to be able to lead these meetings. We would have had a group of senior managers taking about a project that got at the heart of how LTC did business with no real agenda for these meetings. As I found out in the course of the project, LTC was an information-starved company and very few people had a good idea of the real internal financials of the company. The most likely result of these planned meetings would have been tangential suggestions and demands that would have misdirected the project.
One of the lessons we learned from this project was how important it is to manage the meetings around a project: early meetings should be held with those necessary to get the project done but large meetings with the simply interested should be avoided until the leaders can bring a lot of understanding and direction to the meetings.
The first set of planned meetings didn't actually happen, which was a very good thing. Our manager wanted us hold bi-weekly meetings with managers from across the marketing organization. These meetings would have been a disaster.
We didn't know enough about LTV in general and customer behavior at LTC in specific to be able to lead these meetings. We would have had a group of senior managers taking about a project that got at the heart of how LTC did business with no real agenda for these meetings. As I found out in the course of the project, LTC was an information-starved company and very few people had a good idea of the real internal financials of the company. The most likely result of these planned meetings would have been tangential suggestions and demands that would have misdirected the project.
One of the lessons we learned from this project was how important it is to manage the meetings around a project: early meetings should be held with those necessary to get the project done but large meetings with the simply interested should be avoided until the leaders can bring a lot of understanding and direction to the meetings.
Saturday, April 5, 2008
LTV at LTC: Project Approval
The first step of the LTV project was to get IT approval and budgeting. In order to get the project used we needed to get the results loaded into the company data warehouse; in order to get that load we needed IT support. At the time we were also planning on having the LTV production system managed by the IT department; fortunately we wound up running the production system ourselves.
LTC had just instituted a strict resource allocation process for IT projects. Each project had to be justified in terms of return on investment based on financial analysis and passed by a committee of representatives of the various branches of the business. On the face of things this is a very straightforwards process but LTV was almost wrecked here.
The first issue was that customer value was a substantial change from the way LTC thought about customers. LTC had been committed to maintaining all their customers and fighting attrition (customers leaving the company) across the board. The idea that some customers were more valuable than others, and in fact some customers cost LTC more than their were worth, was a foreign concept. Because LTV represented a new way of thinking about the business the LTV project could not be valued in the attrition-based results metrics that were approved for use.
The second issue is that the IT project approving committee was composed of representatives from a broad spectrum of departments in LTC. In theory this was to ensure that the projects that were approved would be useful to the entire company. In practice, projects were decided on by committee members that had no IT experience, no experience in the processes of other departments, and not enough time to truly research the issues they were being asked to decide on. What happened was that projects got decided by corporate politics: the person reputation of the executive champion.
It was in getting our initial approval that our executive champion (EC) shone. Our EC had a considerable reputation within the company. It terms of making the ROI cutoff, what we did was to figure out the attrition gain necessary to make the cutoff and the EC promised to delivery that gain. We knew that the LTV system wasn't targeted at reducing attrition per se, but we also knew that if the project was at all successful getting approval after the fact would not be an issue.
The long approval process did have a substantial benefit: the series of meetings made most of the company aware of the LTV project.
LTC had just instituted a strict resource allocation process for IT projects. Each project had to be justified in terms of return on investment based on financial analysis and passed by a committee of representatives of the various branches of the business. On the face of things this is a very straightforwards process but LTV was almost wrecked here.
The first issue was that customer value was a substantial change from the way LTC thought about customers. LTC had been committed to maintaining all their customers and fighting attrition (customers leaving the company) across the board. The idea that some customers were more valuable than others, and in fact some customers cost LTC more than their were worth, was a foreign concept. Because LTV represented a new way of thinking about the business the LTV project could not be valued in the attrition-based results metrics that were approved for use.
The second issue is that the IT project approving committee was composed of representatives from a broad spectrum of departments in LTC. In theory this was to ensure that the projects that were approved would be useful to the entire company. In practice, projects were decided on by committee members that had no IT experience, no experience in the processes of other departments, and not enough time to truly research the issues they were being asked to decide on. What happened was that projects got decided by corporate politics: the person reputation of the executive champion.
It was in getting our initial approval that our executive champion (EC) shone. Our EC had a considerable reputation within the company. It terms of making the ROI cutoff, what we did was to figure out the attrition gain necessary to make the cutoff and the EC promised to delivery that gain. We knew that the LTV system wasn't targeted at reducing attrition per se, but we also knew that if the project was at all successful getting approval after the fact would not be an issue.
The long approval process did have a substantial benefit: the series of meetings made most of the company aware of the LTV project.
Friday, April 4, 2008
LTV at LTC: A Unusual Start
My involvement in the project started in January 2002. I was managing a modeling / statistical analysis group in the marketing department of LTC. We had a consultant do an initial proof-of-concept and it became my job to fully flesh out the approach and put LTV into production.
Already, the project was off to an unusual start. I was simultaneously
Usually, these are four different people. I believe the project's success was do in no small part to all four roles being being condensed into one person. Whenever issues came up I could simply make a decision instead of having to a) document the issue b) have meetings on the issue c) discuss possible solutions d) document the final solution e) get written agreement on the change from all parties f) finally implement the solution.
For larger projects it may not be possible to be as concentrated as this, but I do think there needs to be one vision behind the project, someone who understands both the technical aspects and the business aspects of the project. Without one person that has a deep understanding of the different aspects of the project and can share that understanding with the rest of the team, none of the parts of the project will fit together.
Already, the project was off to an unusual start. I was simultaneously
- The primary business owner/ representative.
- The project manager.
- The chief analytic designer.
- The head of implementation.
Usually, these are four different people. I believe the project's success was do in no small part to all four roles being being condensed into one person. Whenever issues came up I could simply make a decision instead of having to a) document the issue b) have meetings on the issue c) discuss possible solutions d) document the final solution e) get written agreement on the change from all parties f) finally implement the solution.
For larger projects it may not be possible to be as concentrated as this, but I do think there needs to be one vision behind the project, someone who understands both the technical aspects and the business aspects of the project. Without one person that has a deep understanding of the different aspects of the project and can share that understanding with the rest of the team, none of the parts of the project will fit together.
Sunday, March 30, 2008
LTV at LTC
I've written quite a bit about unsuccessful Information Engineering projects; now I want to write about a successful one.
How can you change a company? Give people the information they need to make decisions they never thought they could and that changes how they think about the enterprise. The trouble is, any organization will put up a lot of resistance to change.
In 2002 I managed a Life-Time Value (LTV) project at a Large Telecommunications Company (LTC) that did change the enterprise. LTV is an attempt to measure the overall economic impact of each customer to the enterprise over their expected life. Ideally this is concrete numeric data so we can ask “Is this customer worth $300 in new equipment for them if they will stay with us for two more years”?
The LTV project allowed people to think about the business in new ways, the project was embraced by the Chief Marketing Officer, and the project saved $15 million each year in direct marketing costs while adding to the revenue from marketing programs simply by not spending money to retain customers that LTC was losing money on.
There are a lot of articles about how to do LTV calculations. This time I want to talk about all the corporate politics around sheparding the LTV project to success.
How can you change a company? Give people the information they need to make decisions they never thought they could and that changes how they think about the enterprise. The trouble is, any organization will put up a lot of resistance to change.
In 2002 I managed a Life-Time Value (LTV) project at a Large Telecommunications Company (LTC) that did change the enterprise. LTV is an attempt to measure the overall economic impact of each customer to the enterprise over their expected life. Ideally this is concrete numeric data so we can ask “Is this customer worth $300 in new equipment for them if they will stay with us for two more years”?
The LTV project allowed people to think about the business in new ways, the project was embraced by the Chief Marketing Officer, and the project saved $15 million each year in direct marketing costs while adding to the revenue from marketing programs simply by not spending money to retain customers that LTC was losing money on.
There are a lot of articles about how to do LTV calculations. This time I want to talk about all the corporate politics around sheparding the LTV project to success.
Friday, March 21, 2008
Good Data, Bad Decisions
Barnaby S. Donlon in the BI Review (http://www.bireview.com/bnews/10000989-1.html) gives a good description of how data goes to information, to knowledge, and then to decisions. He's saying all the right things, and all the things I've been hearing for years, but you know -- I don't think it works anything like that.
When we start with the data, it's all too much. It's too easy to generate endless ideas, endless leads, endless stories. I've seen it happen when an organization suddenly gets analytic capability.
Before, the organization was very limited in it's abilities to make decisions because they had limited information. The organizational leaders have ideas, and because of the lack of information they have no way of deciding what is a good idea or a bad idea. After the organization starts an analytic department, then suddenly every idea that the leadership gets can be investigated. The paradoxical result is that the leadership still can't make informed decisions. Every idea generates an analysis, and virtually every analysis can generate some kind of results. Without data, the result is inertia; with too much data the result is tail-chasing.
The right way to do this is to begin with the end. Think about the decisions that need to be made. Then think about how to make those decisions in the best possible way. Starting with the end means the beginning -- the data, the analysis, the information -- is focused and effective.
When we start with the data, it's all too much. It's too easy to generate endless ideas, endless leads, endless stories. I've seen it happen when an organization suddenly gets analytic capability.
Before, the organization was very limited in it's abilities to make decisions because they had limited information. The organizational leaders have ideas, and because of the lack of information they have no way of deciding what is a good idea or a bad idea. After the organization starts an analytic department, then suddenly every idea that the leadership gets can be investigated. The paradoxical result is that the leadership still can't make informed decisions. Every idea generates an analysis, and virtually every analysis can generate some kind of results. Without data, the result is inertia; with too much data the result is tail-chasing.
The right way to do this is to begin with the end. Think about the decisions that need to be made. Then think about how to make those decisions in the best possible way. Starting with the end means the beginning -- the data, the analysis, the information -- is focused and effective.
Subscribe to:
Posts (Atom)
