KnowledgeForward

Note: This is a cross-posting of an entry I did in the official Collaboration and Content Strategies blog.

In my telebriefing on “Preparing a Business Case for Collaboration” I was pleased with the great questions that were submitted. I’ve posted them here along with my answers.

Q: You mentioned “managing high expectations” [as a risk factor for collaboration projects]. How do you recommend a deployment strategy strike a balance between addressing enterprise-wide expectations with focused hand-holding deployments? In other words, a great solution for a few or a plain-vanilla for everyone?

A: This is a difficult issue to address since in many cases one benefactor is footing the bill for collaboration technology that can be used by many users. Naturally that benefactor expects it will be customized to meet their needs over those of the non-paying masses. If you truly think the solution meets only a narrow niche in the organization, I’d recommend examining the following strategies:

• Try to find basic infrastructure that can be customized (i.e., templates) to meet the benefactor’s needs today and then, when business needs justify rolling it out to more users it is be customized to meet other needs as well.
• Try to hunt down one or two more areas of the business that can split the cost of the project in return for balancing the requirements to meet everyone’s needs.
• Talk to a CIO that is above the benefactor and see if he/she can exert pressure to generalize the requirements or chip in on the price to give the rest of the organization a say in the capabilities needed.
• A last resort is to purchase a niche product to meet their very specific needs (hopefully it’s not too expensive or maintenance intensive) and put governance in place to make it clear this is not for the entire organization.

Q: How would you overcome cultural roadblocks to Collaboration deployments?

A: To be clear, there are generally not many cultural roadblocks to the collaboration technology itself other than the difficulty in getting people to learn a new interface. The roadblocks are all non-technological. And there’s no silver bullet either. But your question was what have I seen used in practice to overcome them. Here are a few that I’ve seen in practice

• Big splashy rollouts: Meeting in the company cafeteria, catchy names and slogans, balloons, little knick-knacks to put on the desk. This generally causes a small spike in usage but doesn’t go much further. In theory if awareness was the only roadblock this could work, but it usually isn’t.
• Changing performance reviews to emphasize collaboration: Some organizations have realized their review processes focus exclusively on individual performance and have altered them to take collaboration into account. This can be in the form of qualitative ratings (obtained by talking to peers, work on team projects) or quantitative measures (social networking ratings). One always has to be careful when tweaking performance evaluations, but this can be part of a good strategy if individual performance is being exclusively emphasized when teamwork is needed.
• Internal research: Most organizations don’t really know the reasons collaboration is being avoided so imposing solutions is a shot in the dark. In this case it is a good idea to actually talk to people from the executive office to staff workers in short interviews and determine their views on collaboration and why it does/doesn’t occur in their area. This is often done by external consultants to encourage anonymity. Formal network mapping can provide a more extensive look at where the informal collaboration networks in organizations lie and where opportunities are being missed.
• Changing incentives: In cases where specific incentives are often tied to individual behaviors (e.g., salespeople), formulas are sometimes tweaked to provide better compensation for collaborative efforts. This can be very tricky, but probably needs to be addressed if the behavior being incented doesn’t match the collaborative needs of the organization.
• Removing inferior alternatives: Eliminating shared drives while making information workers aware of team workspaces can tip their behavior in favor of collaborating. It’s no guarantee - they may simply walk files over on a thumb drive or email them too, but it eliminates one avenue. I’ve seen the same done with e-mail attachment limits as well, although there are sometimes good reasons to e-mail large files rather than posting them to a workspace.
• Leading the horse to water: Sometimes collaborative tools aren’t used because there is no established pattern of behavior. They simply haven’t used them and are more comfortable with the old ways. In these cases, a mandatory activity that forces usage of the tools at least once exposes them to the technology. Just like coupons are, in part, to establish patterns of behavior, these efforts can get information workers used to a technology as well and if they see a need for it soon thereafter, they may use it. Examples include requiring status reports to be filed on a wiki, requiring time off to be noted in a shared calendar, or requiring presentations for an internal conference to be uploaded to a workspace.

Q: Do I have an example of this methodology being used for a government agency?

A: I don’t have completed examples I can give you. I do have a template that guides you through the sections that I showed briefly in the presentation and in more detail in the Methodology and Best Practice document I published on this topic (Building a Business Case for Collaboration Initiatives). If you’re working on a business case I’m also happy to talk to you and give advice as well as give it a once-over before you send it to your management to see if it can be strengthened.

Q: Can I get a copy of the slides?

A: Yes, they are posted on our website here. You can also hear a replay of the telebriefing there as well.

I wrote in a previous posting about all the negative possible meanings of the word “collaboration”. But we view collaboration as a beneficial activity for a company - one that is core to its ability to plan, react, and compete. Accordingly, the question I want to address today is this: How does a collaboration technology strategy act as an enabler for a business collaboration strategy?

I think of business collaboration as the way a non-technical person from the business side of the organization would think of collaboration. Collaboration with partners will be thought of first by a business person in terms of legal, financial, organizational, and business processes. They will generally not (and should not) think first of web conferencing, wikis, and document libraries. But is it possible to do complex, large-scale business collaboration at a competitive rate of speed and efficiency without collaboration technology to support it?

There are a few examples that come to mind that illustrate the need for business collaboration and, underneath, the need for collaboration technology.

Business collaboration for planning

Let’s take collaborative planning as a first example. A July 2007 survey in The McKinsey Quarterly called “Better strategy for business units: A McKinsey Global Survey” discussed the positive impact a collaborative approach has when formulating business unit strategy:

According to this analysis, executives who are satisfied are the likeliest to describe the process at their companies as collaborative. Specifically, executives at companies with a collaborative approach to strategy represent 37 percent of the sample but 42 percent of those who are satisfied with their process.

This quote refers to business collaboration - corporate and business unit executives working together, sharing information and ideas, to create the best strategic plan for their business units possible. This no doubt includes meetings, approval cycles, and changes to incentive plans. But could this business collaboration be successful without collaboration technology to support it? Technology such as information sharing mechanisms, approval workflow, and meeting coordination - just for starters - would enable this business collaboration to take place. I doubt they could put an ROI figure on the technology in this case just as they can’t put an ROI figure on the business collaboration (or even if they could they couldn’t precisely determine the percentage of impact to allocate to the technology), but without it the business would have difficulty functioning.

Business collaboration for reacting and competing

Now let’s look at an example on the impact of collaboration on a company’s ability to react and compete. A very public and stark example can be found by examining what happens when an impenetrable and formal barrier to collaboration, such as a legal one, is removed. The Glass-Steagall Act, particularly its enhancements from the 1950’s to strengthen the wall between insurance and banking, provides a great recent example since it acted as a formal barrier to collaboration in the financial services industry.

So what happened to insurance and banking firms that did not have collaboration technology in place at the end of 1999 when Glass-Steagall was repealed (by the Gramm-Leach-Bliley Act)? After all, there was an open field for exploiting scale, reach, and synergies the likes of which had not been seen before in the industry. Merger and acquisition activity was rampant; the land grab was on. There was a strong need for business collaboration. Indeed, a 2004 presentation (about 4 years after the repeal of GSA) on CONDITIONS AND TRENDS IN THE INVESTMENT BANKING INDUSTRY by SunTrust Robinson Humphrey (available here) said that “Since the repeal of Glass Steagall in late 1999, commercial banks have aggressively pursued highly profitable investment banking operations.” This was just one factor in a consolidation trend, but a major one. The presentation goes on to address what this means for service providers and calls out the “Collaboration required between corporate and investment bankers”

But timing is everything. The implementation time for collaborative technology (as a rule of thumb I’d say 1 year for technology and 1 more year for a base level of adoption) generally exceeds the reaction time that business collaboration initiatives require.Therefore, the collaboration technology underpinnings must be in place before a business collaboration initiative appears on the horizon. This is quite the opposite of how many organizations treat initial collaboration technology acquisition - as a reaction to specific events.

I have not seen an academic study that has determined the correlation between a large corporation’s collaboration technology maturity in 1999 and their subsequent position after the shakeout. There’s a great PhD thesis in there for someone. But I believe it’s no coincidence that when I look through the list of clients of our collaboration and content strategies service, insurance and banks form a large percentage of our client base. And in my consultations with these clients over the last nine years I have found that the large ones - the ones that do the most acquisitions and exploit the most synergies between business units - to have consistently been strong proponents of collaboration technology.

Business collaboration requires collaboration technology (and I need it yesterday)

Of course, I could also have written an entire article about how a culture that encourages and rewards collaboration is also required and must be in place before business collaboration is needed. And maybe I will write that article … at another time.

My point here is that while businesses need to be driven by business “collaboration” rather than technology, most business forms of collaboration require technology to support them. And the technology strategy planning cannot wait until the business details of the collaboration are worked out. Organizations need to understand that 1) business collaboration is omnipresent in the business climate and is often required quickly and without warning. 2) Collaboration technology enables business collaboration. Therefore, 3) a collaboration technology strategy must be in place to enable future business collaboration initiatives.

I’ve just completed a chunk of travel and am diving back into my report on business cases. It was democratically determined by my team that I’ll be focusing on business cases for collaboration (not really in the generic sense, but any number of technologies, projects, or organizational changes related to collaboration that involve technology) rather than KM. That’s fine with me - just as I don’t mean my report to cover collaboration generically, I never meant it to cover KM generically either. My findings will be quite applicable to other discplines that often support KM-type efforts like content management and portal as well.

I thought I’d post up the working outline that I recommend for a business case for collaboration. There’s a lot more detail I’m working on, but here’s how it looks at a high level:

• Section A: Initiative Data Sheet
  • Basic Data
  • Scope
  • References to Related Business Cases
  • Main contributors to this document
• Section B: Executive Summary
• Section C: Business Drivers
  • Business Imperatives (Lean cost structure, Competitiveness, Globalization, Innovation, Responsiveness, Sourcing)
  • Business Drivers / Pain Points (i.e., Co-location, Complexity, Cost reduction, Crisis management, Cross-boundary processes)
• Section D: Proposed Solution
  • Proposal details
  • Collaboration Capabilities (Brainstorming / swarming, Coordination, Information pooling, Knowledge capture / sharing, Workflow)
  • Metrics and Success Criteria
• Section E: Analysis
  • Analysis of Past and Present Business Environment and Trends
  • Expected Change in Information Worker Productivity
  • Analysis of End User Enablement
  • Collaboration Maturity Analysis
  • Competitive Analysis
  • Analysis of Past Failures
  • Use Case Analysis
  • Analysis of Alternatives
  • Risk Analysis and Critical Assumptions
  • Financial Analysis

If there are any methods you’ve seen work in business cases that aren’t on here, please drop me a comment and let me know.

I’ve just completed a chunk of travel and am diving back into my report on business cases.  It was democratically determined by my team that I’ll be focusing on business cases for collaboration (not really in the generic sense, but any number of technologies, projects, or organizational changes related to collaboration that involve technology) rather than KM.  That’s fine with me - just as I don’t mean my report to cover collaboration generically, I never meant it to cover KM generically either.  My findings will be quite applicable to other discplines that often support KM-type efforts like content management and portal as well.

I thought I’d post up the working set of headings that I recommend could be in a business case for collaboration.  I say “could” because this is a laundry list of what could go into the case, but it would probably obscure the point to put them all in.  The trick is to go for the path of least resistance - pick the sections that best make your argument and that the approver of the business case is most responsive to.

• Scope and methodology
• Relations to other business cases or initiatives (linked or nested business cases)
• Analysis of past and present business environment and trends
• Alignment to business objectives
• Analysis of information worker enablement
• Expected change in information worker productivity
• Competitive analysis (IT spending survey, etc).
• Examples of past use cases
• Examples of future use cases
• Financial analysis:
  • Expected change in cash outflow / expenses (discounted over time) with proposal:
  • Expected change in cash outflow / expenses (discounted over time) status quo:
  • Expected change in cash inflow / revenues (discounted over time) with proposal:
  • Expected change in cash inflow / revenues (discounted over time) status quo:
  • Financial analysis
• Metrics and criteria for success

I’ll have another section on meta-business case arguments that attempt to rethink the basic business case model at a different spot in the report.  If there are any methods you’ve seen work in business cases that aren’t on here, please drop me a comment and let me know.

When talking to clients about business cases for portal, content management, collaboration, or intranets I have found that they jump too quickly into their spreadsheets or lists of benefits.  Before jumping into the number crunching, it’s worth taking a step back to look at what is really being asked for. The intention of this list is to help business case authors to be aware of the catches and pitfalls, to know the questions to ask of their peers and financial folks, and to lay out the territory so they can avoid unnecessary work and find the path of least resistance to gaining approval.

Some questions to ask to assess the situation before diving into the business case:

Why me? Did every initiative have to have a business case? Did e-mail?

Business Case vs. Business Plan: Are you producing a business case (presented to a decision maker who will judge whether to proceed with the direction recommended in the plan) or a business plan (done after a business case is accepted and contains all sorts of things the judge probably does not need to know such as the phasing and schedule, staffing plan, and project plan)?

Business case vs. ROI: A business case is not necessarily numerical. Providing a spreadsheet when the boss expected a textual business case can sink your project, or at least waste a lot of time.

ROI, NPV, IRR, payback, TTV: If you’re doing quantitative analysis, do you have a choice of method? Are the time period and discount rate specified? If not, this just becomes an exercise in picking the most favorable parameters you can get away with.

Conceptual vs. Concrete: How fuzzy (“collaboration in the workplace”) or concrete (a specific product) is your initiative? Do you have the option of how to scope it? Business cases can be at many different levels: Technology, program/project, Organizational, and Conceptual

Project vs. infrastructure: A project has a discrete beginning, middle, and end. Infrastructure is ongoing. Quantitative analysis such as ROI was made for discrete projects and is difficult to apply to infrastructure where one does not know exactly all the ways in which the enabling infrastructure will be used. Also, the infrastructure simply makes other assets more efficient (people, systems), rather than directly providing benefit itself, so determining what percentage of improvement is due to the boost provided by the infrastructure is like trying to determine how many milliseconds faster a runner is because of the vitamins she is taking. One common way around this problem is to “projectize” the infrastructure: to take one major and immediate way in which the infrastructure will be used and justify its entire cost based on that project, treating the rest as free icing on the cake (“And we’ll get to use it for other things too …”).

Hard vs. soft: You can think of both costs and benefits as being on a hardness scale like the 1-10 one used in the Mohs Scale of Mineral Hardness. Provable, measurable impact to a company’s profit through increase of revenue or decrease of expenses, accurately attributable to a direct cause, is a diamond (10). And it’s equally rare and valuable. On the other hand, “It will save every salesperson 5 minutes per day” is talc (1). Simple, easy, and soft. Helping to decrease printing expenses by providing information online is maybe Orthoclase Feldspar (6. OK, I looked it up on Wikipedia). No non-investment business could function if it required a rating of 10 on benefits and costs for everything it did. Some faith (faith = (10 - hardness rating) * 10%) is generally involved.

Net benefit vs. status quo: Generally the status quo – the current state cost of doing nothing and proceeding as always without the infrastructure project – is incorrectly assumed to have a cost and benefit of $0. This math ignores the possibility that the status quo itself may have costs and benefits, particularly if the environment is changing in some way.

Prioritization vs. financial testing: The effect of the project on the time and money of the company and attention of your team and those touched by the project (including the end users) needs to be prioritized against other potential projects. On occasion, KM project owners jump through many financial hurdles only to find their project rejected anyways since other projects were deemed more important or worthy of the effort.

Lottery vs. followup: Is the business case treated as a lottery where winning results in a pile of cash showing up at the door? Or does the eye of the finance department continue to watch you after you win approval? You should have to show you actually used the resources allocated for the project in question and got the benefits you promised.

I’ve been an analyst since 1998, focusing most of that time on various knowledge management technologies like portal, web content management, and intranets.  One client inquiry that has been consistent over time and between technologies is the need to prove value for knowledge infrastructure.  Sometimes this takes the form of financial analysis (ROI, NPV, time to payoff), and sometimes it is around metrics (how can I show improvement or prove in a year or two that it was worthwhile).

Overall, there are two reasons owners of collaboration infrastructure start work on a business case: because they have to and because they know it’s good for them. There’s an inbetween option which is that it behooves them to do it now because there’s a good chance they’ll be asked for it in the future. Even if not explicitly asked for, a business case should be an integral part of any collaboration plan or strategy to validate that the technology is aligned with business goals and objectives.

The journey is the destination when it comes to business cases. When the business case creation process is seen as valuable on its own rather than just a hurdle to get past to start work it can be used to steer the direction of the project and form the basis for an ongoing dialogue with the business.

At a high level, the business case for technologies that fit under the KM umbrella are very similar (portal, web content management, attention management, intranets, collaboration, search, etc.). Note that I will not distinguish between the business case and a business justification. The differences are very minor and lead to the same steps in my experience.

I’ve talked to 100+ organizations about their business cases over the past 7 years, worked in detail on a few, have read through many case studies, and have seen many different approaches that worked at different companies. It’s all about 1) starting with a worthy project, 2) understanding the situation – the why, what, and how, 3) building the business case by selecting the most useful methods out of the many available for the specific situation and the line items to apply those methods on, 4) presenting the business case (in multiple formats), 5) keeping the business case in mind while executing the initiative, and 6) following up once the initiative is in place.

That represents my high level view of this issue. I’ll post more thoughts in an ongoing fashion. I’ll focus on #2 since I think that’s where most of the misunderstandings occur and business case production often goes astray.