“Appropriate Empowerment” is the third and final element of the Holy Trinity, the three essential characteristics of sponsors of successful analytics practices, covered in the current series of posts. Appropriate Understanding and Appropriate Incentive were covered previously.
As before, this is an examination of the success mode and failure modes of the element in question. What does Appropriate Empowerment (or just “Empowerment” for short) look like when it succeeds, and what happens when it fails, or other elements fail to support it ? The success mode of Empowerment considers the situation where all elements of the Trinity are in place, but focuses on the role played by Empowerment.
The Failure Mode of Empowerment is the situation where the sponsor possesses Understanding and Incentive, but lacks Empowerment. We explore this situation, along with possible remedies, before concluding with the Isolation Mode, the situation where Empowerment is present, but alone, with neither Understanding nor Incentive in place beside it.
The success mode of Empowerment is simple, yet essential. Empowerment is the least visible element of the Trinity, more notable in its absence. Where the Sponsor sees the need for something to be done to the benefit of the business through analytics, and has the right Incentive to make it happen, then Appropriate Empowerment simply means : it happens. There is no one who can overrule, block, derail or otherwise unhelpfully modify any analytics initiative that has been put into motion.
Understanding ensures that the sponsor identifies the right analytics initiative for the greatest benefit to the business, and takes into account all that is required to enable it. Incentive ensures that the Sponsor actually wants this to happen. Empowerment then is simple : the Sponsor is in a position to launch the initiative, and ensure that it proceeds to the correct conclusion. He is able to support it with all the resources it requires, and protect it from unhelpful stakeholders. He is also in place to ensure that recipients of analytics recommendations act on them if the process requires them to do so. Tyrannical ? Perhaps. Far-fetched ? Certainly. But this is the ideal, however out of reach it may be for (current) real-world large organisations.
Empowerment is thus quite simple. It is the ability to make things happen.
It is also an absence of unhelpful constraints. A Sponsor with the Holy Trinity is sufficiently empowered not to worry about unreasonable or ill-defined expectations of value before the initiative or function is ready. Empowerment ensures that the function is not subject to IT-style management practices, deterministic waterfall and project management approaches. His analytics function is lean, agile and experimental : free to learn, fail repeatedly (for a time), as required to continually reach insights of massive value and exploit them.
The failure mode sets in when a sponsor has all the best intentions in terms of Incentive, and is well versed in Understanding what an analytics function can do, and what it requires to achieve it, alongside budget and a mandate to create the analytics function. Unfortunately, he may well lack the power to act as Understanding and Incentive may compel him to.
Any dilution of empowerment invites unreasonable expectations born of poorer Understanding and Incentive. A sponsor beholden to other managers, stakeholders etc is subject to constraints, expectations and pressures that may prevent an agile, experimental approach. The cargo cult of analytics, “Analytics in a Box” solutions promoted by some vendors stand in opposition to the agile approach, and enjoy attention and support from far too many senior executives. The resulting analytics cargo cult, subscribed to by much of senior management, expects great value from analytics, but does not know how to define this value, or even to measure it. This very lack of clarity may be what imposes inappropriate deterministic project management frameworks such as PRINCE2, and other inappropriate business analysis and management oversight by people who have no idea what they are managing or why. in such situations, project managers may grab the first objective metric, however irrelevant or minor and focus on it as a box ticking exercise. The analytics function is then little more than an IT production line, creating something of indeterminate value to satisfy a management fad. A sponsor beholden to such powers cannot be said to be sufficiently empowered. Worse yet, ignorant or indifferent management may relegate the sponsor under the auspices of IT. Needless to say, this is not an ideal outcome.
One large pathology crippling Empowerment is the modern corporate stakeholder model. A committee of stakeholders is not a Sponsor, especially when enough members of that committee have far from perfect Incentive or Understanding, and perhaps far too much Empowerment. A committee can be on the whole more stupid, poorly Incentivised and disempowered than any one member. A Sponsor beholden to such a Committee is hardly empowered, and the Committee as Sponsor is a far from ideal scenario. The fact that this situation is reality in so many large organisations does not diminish the fact that it is utterly pathological.
In the ideal situation the Sponsor is beholden to no one with excessive power who is inadequate in the other two key characteristics. The ideal Sponsor is therefore the CEO, and better yet a manager / owner. Again, this is perhaps unrealistic, but still needs to be identified as the ideal, and any deviation from it analysed in terms of potential failure of Empowerment. It is also the reason that the most innovative, valuable and agile analytics exist in tech startups and not large “Enterprises” (in quotes because they are usually the very opposite of that word)
Not all pathologies of Empowerment concern levels of power above the Sponsor. Other pathologies of Empowerment are lateral. The most immediate lateral power issue is one with IT : too many IT functions find it their job to block analytics access to tools, especially open source tools that are otherwise readily available, free and powerful. They may prevent access to adequate, and otherwise cheap and readily available hardware and useful online services such as cloud computing. They are also known for starving the analytics function of data. Too many analytics functions are in a situation where the main expenditure of effort is building business cases for data, tools and hardware. A sponsor who knows this to be the case but cannot fix it is clearly not sufficiently empowered.
Lateral Empowerment is also an issue with “trigger pullers”, people whose job it is to act on the recommendations of operational analytics. The most striking case of this is a pathology i have seen in a multitude of organisations making use of predictive operational risk analytics. Predictive models provide lists of targets (eg revenue leakage, non-compliance, suspicious behaviour, fraud risk indicators etc). In all cases a human being is provided a list of targets generated by the predictive model. Ideally, this human being proceeds to manually investigate the targeted cases. Unfortunately, in most situations, these individuals do not understand or trust these predictive models. In my experience, many such individuals cannot conceive the very idea of the inference of a model from data. It would appear that there are whole cultures of people who cannot imagine such a thing as statistical induction. They naturally voice their displeasure and challenge, stall and undermine the process. Much of a Sponsors job seems to be the thankless, draining and often never ending task of “winning them over”. A sufficiently empowered Sponsor would, however, be in a different situation. When asked why these people should trust these models he would be able to answer “because if you do not, I will fire you and perhaps hire someone who does what they are told. Or replace you with a smart pattern matching algorithm”. Again, this is perhaps not realistic, and perhaps suggesting something that certain Public Sector Unions would consider on par with a crime against humanity – asking that people do their jobs. The whole issue of uncooperative “trigger pullers” was only raised to make a point about Appropriate Empowerment: if a Sponsor is not able to ensure that human components of an operational analytics value chain do cooperate and act as a part of the analytics value chain, there is a failure of Empowerment. Perhaps effective analytics sponsorship, as defined in this series is impossible in most organisations where employee non-compliance and stakeholding is a given.
A lack of Empowerment is however, far from the end of the world, and the relatively dystopian situation described above matches many existing analytics functions, particularly in government and quasi-government organisations. They still manage to survive, and add some value, although arguably but a fraction of what would be possible if only sponsors were more Empowered. These organisations have in fact found themselves innovating in a number of fronts, dealing with insufficient Empowerment, and in some cases developing methods of generating more of it.
One key solution to the problem of insufficient Empowerment is Separation from IT. As far as possible, as quickly as possible, it is important to establish a “sandpit environment”, separate from the main IT network, where new hardware may be added, and software loaded outside of IT governance. This is essential if appropriate computational power and open source tools are to be leveraged quickly and effectively.
Another part of the solution, and one that is even more fundamental is Stealth Mode. It is imperative that a new analytics function has the ability to learn, experiment, and fail in its early stages. Expensive budget items such as vendor tools create massive, thought ill-defined expectations. Expectation management is yet another reason to avoid expensive vendor software early in the creation of an analytics function.
Ideally, the function has a small crew of capable, flexible people, a small budget and access to data and open source tools. Also, the function has a main focus that is a well-defined, business as usual task such as reporting. Actual analytics can be done on the side, as a side project, and not announced until it yields results. These results can then be presented as wins to formalise and Empower the nascent analytics function. There may then be sufficent leverage to acquire more staff, create a sandpit environment and acquire data reliably.
As discussed previously, the most important element of the Trinity is Incentive. With Incentive alone, the Sponsor knows that their first task is to increase their Understanding. Some of this is reading/study, some of this is consultation with experts, and much of this is experience which can be obtained in stealth mode. Empowerment is important, but as we can see it comes third in importance.
Indeed, most capable analytics professionals find themselves working for under-empower sponsors. This is not ideal, but not a career-ending situation. Indeed, the struggle for further Empowerment of the Sponsor is the defacto KPI of most analytics functions, and many professionals find it as exhilarating as they may find it frustrating.
It remains to discuss the “Isolation mode” of Empowerment. What happens when the Sponsor has all the power, but no Understanding, and,lacks the right Incentive? Here ignorance conspires with either a lack of real enthusiasm for Analytics, or an entirely different agenda, and gives them a hefty cheque book. So, what can happen ? A storm of Cargo Cults, management fads and buzzwords. “Analytics”, having something to do with “data” and software must clearly be some kind of IT, best managed and bought by the CIO and best explained by people who sell software. And that’s how the wrong kinds of Vendors happen. Long sales lunches. Exciting pre-sales presentations. Use of the words “Enterprise”, “Innovation” and “Insight” by people who don’t have anything to do with any of them. “Case studies” of previous such exchanges in other high profile corporations, presented as success. People who may not really care what they are selling, sell to people who don’t really understanding or care what they are buying. Consultants, the “best practice”, “brand recognition” kind jump in. More money gets spent. Everybody involved wins, except the (theoretical and distant) shareholders, citizens and other ultimate beneficiaries of the business. Almost always, none of the parties is an actual owner of the business in question. Most owners are far more sensible than that.
So what happens after that? Software get installed. Systems get integrated. People get hired, maybe, as an afterthought to mind the (far more important) Machines. These people are likely software developers, data base managers and project managers. Maybe even a token statistician. Gannt charts get ticked. Bonuses get paid (at least on the vendor side). Conferences benefit from new “Best practice” case studies. The Vendor-Consulting complex marches on in all its dinosauric grandeur.
So Incentive and Understanding matter, and Empowerment on its own is not a great idea, however common this situation may be.
In my experience working for and partnering with software vendors I have never once heard of an organisation buying training from a vendor before deciding whether or not to buy its software. I’d be very keen to hear from readers who know of any examples.
Business Analytics software vendors have Education departments: specialist trainers, classrooms, courseware, certification. Their education programs cover beginner through to advanced level instruction in how to use their software. Few individual courses would run for more than five days. Investors in Business Analytics typically send the software’s users-to-be on training in the early stages of implementation, after the software has been selected and paid for.
This seems an opportunity missed. Training is a wonderful evaluation tool, not just of the software, but also of the team who will be using it, and of the degree to which its intended use has been well formulated.
Most software capabilities are asserted through written responses (RFTs, RFQs, RFIs, etc.) and then demonstrated. Demos are created and performed by experts. This shows the software in its best light and illustrates its possibilities. Worth doing.
Some organisations also run a trial evaluation of the software. This tests the software’s compliance with the IT environment and may enable some cursory analyses to be performed using real data. Also worth doing. However the software is typically operated primarily by the vendor’s consultants in these settings – in part because no one from the business has been trained yet.
My suggestion is that an organisation considering spending money on a vendor’s software should first spend money on that vendor’s training. This would enable a superior evaluation of:
- How easy the software is to use in practice.
- Whether the proposed users of the software are suitable.
- The degree to which expectations of increased productivity have been well calibrated.
- Whether the business problems expected to be tackled using the software have been well framed.
- Whether additional tools are required and/or existing tools are being duplicated.
- Whether the business has the sort of data it’s going to need to run various analyses.
- Whether draft project plans are realistic.
There remain some critical things it wouldn’t be able to test, which also don’t get addressed through sales consultation, written responses, or demos:
- The wisdom of the Business Analytics initiative from the point of view of business value.
- The organisational-political environment in which the software is going to live.
- The organisation’s data quality.
- And of course, what’s going to be found when the data gets analysed.
The only apparent downside of this approach is cost. But if an organisation is confident that it’s going to buy the software in question then it’s going to be paying for training anyway. There is no additional cost. If it’s not confident then this makes even more sense as a hedging strategy. Training is a small cost when compared to licensing fees, implementation services and first year maintenance. Upfront training is a smart way to buy an option on the software.
Related Analyst First posts:
The previous post looked at why Business Analytics is a solution selling zone for vendors. It’s also, therefore, a solution buying zone for organisations. Most investments in Business Analytics capability (everything from choosing software through to rolling out applications) are managed as projects. Projects typically result from some kind of strategic initiative, that is, from an attempt to make some kind of lasting change to business as usual. Organisations have standard ways of creating, funding and managing internal projects. The initiation stages of a typical Business Analytics project, involving the evaluation and purchase of enterprise commercial software, would look something like column 1:
|
Solution Buying |
Solution Selling |
Vendor Role |
|
Strategic initiative |
|
|
|
Project team formation |
Event marketing / collateral |
Marketing / Sales |
|
Market review & research |
Sales calls / canned demos |
Sales / Presales |
|
Ratify budget |
|
|
|
Requirements definition |
|
|
|
RFI / RFQ / RFT |
Written response |
Sales / Presales |
|
Supplier long list |
|
|
|
Demonstration round |
Canned / custom demos |
Presales / Sales |
|
Supplier short list |
|
|
|
Further demonstrations |
Custom demos |
Presales / Sales |
|
Identify preferred supplier |
|
|
|
Negotiate contract |
Formal quotation |
Sales / Legal |
|
Buy software |
|
|
|
Begin implementation |
|
Consulting |
Commercial software vendors are structured and organised to solution sell within this framework. Columns 2 & 3 map solution buyer processes to the relevant vendor sales tools and the lead / support functions who use them.
The process of an organisation choosing a supplier of consulting services follows much the same pattern. Professional services firms sell methodology rather than software. Both are products, and their credibility and capabilities get assessed during any sales process. The key difference in sales methods is that software is more about ‘show’ and professional services about ‘tell’.
One obvious feature of the above framework is that it is top-down. This is a common way to develop Business Analytics capability, but it isn’t the only way. Some Business Analytics sponsors choose instead to start bottom-up (or have no choice but to). Both approaches have their strengths and weaknesses. The Analyst First approach can go either way. The top-down approach as outlined above, however, is the default approach. It is also the only possible approach to the extent that investing in Business Analytics entails investing in commercial enterprise software.
The two previous posts have outlined some structural aspects of the commercial software business. If you’re a prospect or customer of a software vendor you’re likely to interact with its employees in the following roles:
Support
- Field and troubleshoot support calls from existing customers, usually offsite.
- Often service a region from a central location (e.g. Sydney might support Australia and New Zealand)
- Maintain exceptional knowledge of software functionality but not of its broader business context.
- Modestly paid, with no sales-contingent component.
Consulting
- Perform project-based software implementation and configuration work, usually onsite.
- Project focused, managed and measured.
- Maintain excellent knowledge of both software functionality and its direct/narrow business context.
- Reasonably paid, with no sales-contingent component.
- Typically no involvement in the sales process.
Presales
- Provide technical credibility to the sales process.
- Typically come from either an implementation or industry background.
- Specialise in speaking both the ‘business’ and ‘technical’ languages, and translating between the two.
- In many respects ‘performers’ who build their own props (demos).
- Maintain a level of technical skill and domain knowledge which in practical terms means they are often locked in to a domain, within which they may move between competitors.
- Paid well, with some sales-contingent bonus.
- Typically no involvement in implementation projects.
Sales
- Coordinate presales, executive, and their own interaction with prospects to bring in new licence revenue.
- Operate in a solution selling environment.
- Maintain general solution selling skills, giving them relative mobility. A salesperson currently selling Business Analytics may have started out selling hardware then moved through RDBMS and ERP systems before arriving at Business Intelligence and Analytics.
- As a corollary of this, maintain relatively little technical and domain knowledge as compared to presales and implementation consultants.
- Paid very well provided their sales targets for new licence revenue (not renewals) are met, often with “double bubble”.
- Sometimes assigned to specific ‘hunter’ (acquisition) and ‘farmer’ (retention) roles; if so, farmers are less generously paid.
- No involvement in implementation projects.
Management / Executive
- Coach, coordinate and motivate sales and implementation teams, maintaining oversight over active opportunities and projects, with direct involvement only on an exception basis.
- The ‘Special Forces’ of the sales process; professional services executives sometimes play ‘fire fighting’ roles in the context of implementation projects; otherwise, no involvement in implementation efforts.
- Paid exceptionally well, especially if revenue targets are met.
This list works its way from low to high pay and status. The last three have little interest or involvement in implementation work except as it pertains to sales in the near-future. These are the people you interact with when you are a prospect. Once you become a customer you mostly deal with the first two.
A previous post explained that solution vendors construct worldviews in which their offerings are optimal and urged prospective investors in Business Analytics to educate themselves accordingly.
A worldview is a ‘framing’ device. As such it pulls certain things into focus, puts others in the middleground, demotes some to background, and leaves much out of the picture altogether. Vendors don’t refer to their worldviews as worldviews, however. Instead they talk about ‘positioning’. Considerable sales, presales, and marketing resources get devoted to the development, refinement and communication of positioning. Vendors are generally very enthusiastic about sharing their positioning with prospects and clients – talking about future product direction is a common example. One reason for this is that vendor worldviews are, for those who have been taught them, powerful and coherent narratives which there is little reason to question.
Most vendors sincerely believe they have the best product, and actually, according to their worldview, they do. Two things enable this belief. The first is confirmation bias, which ensures that positive proof is given more attention that disproof. If my worldview holds that ‘the ability to manage the deployment of models across multiple logical environments’ is important then I will pay particular attention to evidence that this is a client or prospect requirement and be ready to cite use cases. If my worldview holds that ‘the freedom to experiment and develop my own algorithms’ is important then I will have at the ready arguments and examples as to why this matters.
The second enabler of multiple vendor worldviews is arbitrariness. Business Analytics is a large and complex field to which no one can claim exclusive definitional rights. As such there is no ‘official’ way of determining whether different vendor worldviews and substantiating claims are near identical, different but co-existent, mutually exclusive, subsets of each other, or directly at odds. The above two claims in fact have little to do with each other, although the first is typical of commercial software narratives and the second of open source. Who’s to say which is more important?
The lesson here is that organisations investing in Business Analytics need to comprehend and compare each vendor’s implicit worldview, not just their functionality sets. As the earlier post argued, the responsibility for this needs to be owned internally.
It’s also worth noting that vendor worldviews change – faster than the products themselves change.
People who haven’t been intimate with the enterprise software game tend to underestimate the differences between the presales and postsales environments. Those differences exist on both the vendor and buyer sides of the sales equation:
- People: less experienced buyers don’t realise that the people they deal with during the sales process are a different group to those who will be involved in implementation efforts.
- Incentives: vendors’ presales incentives are all designed to make sales transactions occur. Their postsales incentives, on the other hand, are generally tied to professional services and project management targets. These two sets of success criteria are often directly at odds with each other.
- Politics: buyers and sellers both abstract out organisational-political considerations when they are in presales mode. In the postsales mode they become all too real.
- Data: similarly, most substantive data attributes (existence, coverage, history, quality, etc.) are also abstracted out during presales interactions. Postsales applications of Business Analytics are uniquely data-centric. Their success is necessarily contingent on the fitness for purpose of available data. During presales, however, software functionality is usually showcased in idealised data scenarios.
About us
Analyst First is a new approach to analytics, where tools take a far less important place than the people who perform, manage, request and envision analytics, while analytics is seen as a non-repetitive, exploratory and creative process where the outcome is not known at the start, and only a fraction of efforts are expected to result in success. This is in contrast with a common perception of analytics as IT and process.Authors
- Eugene Dubossarsky (43)
- Greg Taylor (4)
- John Lowry (1)
- Richard Fraccaro (1)
- Stephen Samild (87)
- Tapir (1)
Tags in a Cloud
AIPIO analyst first Analyst First Chapters analytics analytics is not IT arms race environments big data business analytics business intelligence cargo cults collective forecasting commodity and open source tools complexity data decision automation decision support educated buyer EMC-greenplum forecasting HBR holy trinity human infrastructure incentives intelligence model of analytics investing in data lean startup literacy management culture MBAnalytics operational analytics organisational-political considerations Philip Russom Philip Tetlock prediction markets presales R Robin Hanson Strategic Analytics tacit data TDWI Tom Davenport uncertainty uneducated buyer vendors why analyst first


