Dec 07, 2004: Funding Enterprise Design Functions

Much of my consulting this past year has focused on ramping up teams--or standalone business units--to tackle enterprise design tasks. As I'm an information architect, these functions typically include enterprise IA tasks, such as improving a main page or instituting best bet search results. But often the scope of these teams bleeds into other areas of user experience, such as branding, usability, accessibility, and content management; enterprise issues are by no means unique to information architecture.

These enterprise design tasks are typically owned--if addressed at all--by a disjointed collection of business units concerned mostly with their own requirements and politics. The needs of the users of enterprise information and the managers concerned for those users often get left out.

That's why I encourage placing enterprise design functions in the hands of a central, stand-alone team or business unit. Such a group has a broad perspective that counterbalances the localized goals of autonomous business units. But our new team will be a cost center; how do we pay for it?

Start by looking inside your organization to see how it's been done before. For example, most enterprises have centralized HR groups or IT departments. Unfortunately, while these existing groups can serve as models for your new team's current funding, they've been around so long that they may no longer be useful models for start-up funding. This means trawling uncharted waters to find the money to jumpstart the group that'll tackle enterprise design; quite a difficult task even for experienced senior managers.

The best approach for both startup and ongoing funding is, IMHO, to hedge one's bets by diversifying revenue streams. (Ugh. Did I really just use that phrase?) Here are a few revenue streams that are worth considering; if you can at least achieve more than one of these, your new enterprise design team will be far healthier in the long run:

Revenue from headquarters/central administration

• Seed Capital: A one-time only investment that senior managers might be willing to make as a show of support for the new group. You'll want to stretch this investment out over a period of years in decreasing amounts, rather than blowing it all at once.
• Operating Expenses: These cover basic costs and infrastructure, like office space and furniture, and may be made "in kind". Not terribly difficult to justify initially, but constantly subject to inevitable belt-tightening measures.

Revenue from other "client" business units

• Flat Taxes: Covers services that business units already are receiving, expect to receive, and may not be paying for right now. Your goal is to get other business units to stop taking such services for granted by affixing a cost to them. Enterprise search system maintenance is a good example of a service that might be covered by an ongoing flat tax.
• Variable Income for Services: Your enterprise design team should sell its services to "client" business units. Such services could range from developing best bet search results to content tagging to production-level graphic design work. This source of revenue is critical in two ways: 1) business units that are new to user experience learn its value by paying for it; and 2) more experienced units can make rational comparisons between your new team's offerings and those of outside agencies and other vendors.
• Variable Income for Special Projects: When an organization tackles large and occasional enterprise-wide projects--such as the installation of a new content management system--the money needs to come from somewhere. Assuming the central administration won't cough up the money to cover a new CMS, the bill will be picked up by those making the request: business units from around the organization.

In an ideal world, with all five revenue streams in play, things might look like this:

Of course, the real world won't be so generous. That's why it's worth examining each angle and shooting for as many of these streams as you can. Some might be viable right away, while others will require years of sales effort on your part before they become real.

Did I leave out any other sources of revenue, obvious and not-so-obvious? Please comment below.

email this entry

Comment: Keith Instone (Dec 7, 2004)

Missed one - stealing. (^:

Seriously - re-orging and assuming the people & budgets that go with it. The people keep doing the same work for the "client" teams that they just left, but they act as a central group, sharing the work better. They will find that they can leverage each other and be less busy than when they were isolated.

Comment: erin (Dec 11, 2004)

My group has responsibility for the UE intranet and other tools as well as providing all the illustration for each business unit's products. We are partially funded by the CPO (Chief Product Officer) budget which covers our operating and resources, some by a flat tax spead out across all the business units and then there are a few things, like the illustration, that gets billed back as it is comissioned. It is an interesting model, but I am constantly trying to figure out how to do more with less since we don't have the typical funding structure of other teams.

Comment: samantha (Dec 15, 2004)

Moonlighting effort, i.e. getting enough talented and passionate folks on your side that they do some or all of the work 'for free' to at least get the project going in their spare cycles. While this strategy is risky and 'unofficial' enough that it probably does not make sense to include in a published revenue model, I've seen it work in both very small and fairly large companies. The times when it has seemed the most successful is when there is a high profile backer to the project who is able to get some folks to basically donate time outside of their regular work with the idea of getting a project started. The eventual cost is that the initial members of the guerilla team often take on the work with the plan of being able to move to that new team permanently once the proof of concept and ROI is complete and the project becomes officially funded.

Comment: Paula Thornton (Dec 16, 2004)

In a related discussion on this topic Lou responded: "...the Zachman model of IA, which is by definition focused on the enterprise. One of its layers claims to address AIfIA-style IA, but that's only in theory; in practice it focuses on technology, not the users or the content that the technology is supposed to serve."

I wrote to him:
Funny...it was almost 15 years ago that I was complaining that Zachman was missing the 'human' side to the picture...that all his deliverables were technology focused. He fails to bring to the table that there are actually three fully repeating dimensions of his layers. He's represented the technical....there's a duplicate for process/business operations and another for human factors/considerations. There is then yet another 'role' to be played to mitigate the melding of the three back together for an implementation.

NO ONE is doing any of this...

Another point that may or may not be an issue (from your perspective it would be because there is so much detail behind the differences), the model only refers to data. While in the global sense I believe we'd be a lot better off if content management applied basic data management concepts (it's simply a data 'type') -- as a particular type it does have some very unique considerations that tabular data does not. They both would be benefited by more robust metadata models to bring the two together (aligned to the 18-odd general dimensions I came up with...all "W"s -- starting with [a Zachman derivative and then some] "who, what, where, when, why, (w)how...anything that defines/describes the 'meta' (essence) of something's existence or absence...often the best definition of a data element was in defining what it was not]. Sorry for the random rant...

I add here now:
We will continue to face 'organizational design' issues in anything we do. Why? Organizations evolved their 'design' from the manufacturing era, when organizational business principles evolved in a new paradigm (no one can question the fact that there has been merchandising for millenia) -- moving away from a fundamental era focused on Agriculture. The early Informational era was in support of manufacturing (operations).

In the 90's we moved from an operational focus to a service focus, but the fundamental organizational structures did not follow suit. Why? There is no one at 'watch' at the switch. Check out the advanced educational programs (I have, once I discovered this potential flaw). There are programs which use the term "Organizational Design". They do not focus on these issues. Instead, under the covers, at the heart they are still fundamentally focused on HR-based issues such as human development (ala. training) -- not the fundamental questioning of how we divide up responsibilites and budgets to align 'focus' to intended results.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.