8 reasons to consider a COE (Part 3)
[Note: For those of you looking for a deeper dive on IT-business alignment, I recently came across two interesting posts here and here. I also have two older posts on the subject here and here.]
This is the last of three posts looking at compelling reasons to consider a COE. In the first two, we examined how COEs can help reduce knowledge management risk, improve the quality of service delivery, and help organizations develop core competencies, retain employees, and create organizational linkages. In this post, we turn to some IT-centric reasons: to improve IT-business relations and rationalize IT delivery timelines.
8 reasons to consider a COE (Part 2)
[A quick editorial note: Thanks to Rick Tucker, who just pointed me to John Mancini’s
“8 Things” page—a great resource that, thankfully, doesn’t appear to have an entry yet for
8 reasons why you should consider a COE, although it has just about everything else covered…I highly recommend it.]
This is part two in a three-part series of posts looking at compelling reasons to consider a COE. In the last post, we examined how COEs can help reduce knowledge management risk and improve the quality of service delivery. In this post, we’ll see some ways that COEs can help organizations develop core competencies, retain employees, and create organizational linkages.
8 reasons to consider a COE (Part 1)
In my practice over the last year, I’ve been doing a lot of work helping clients create and manage centers of excellence (COEs). They’re not a new concept by any means; in one form or another and under a variety of names, they’ve been in use since at least the mid 1960s. But whether it’s due to the increasing pace of globalization, the growth of the virtualized workforce, or the complexity and speed of the marketplace today (or some combination of all three), lately I’m seeing renewed interest in COEs at my clients.
So at the risk of contributing to internet list mania—and incurring the wrath of the boys over at BMOC (see their take on numbered lists here)—I’ve decided to write a series of posts under the umbrella title of “8 Reasons to Consider a COE”, of which this post is the first of at least two, but no more than eight…
But before diving in to reason #1, let’s start with a quick overview of what exactly I mean by center of excellence, because the concept can mean different things depending on who you ask.
No one cares about ECM (Part 3)
In the last post, we looked at two ways to articulate the benefits ECM has for an organization that are compelling to the C-level decision makers: storage and e-discovery. In this post, we examine two additional ECM benefits that have strong appeal for business users at many organizations: customer communication management and contracting.
No one cares about ECM (Part 2)
In the last post, we looked at how important and difficult it is to communicate the benefits of improved content management practices to CXOs. In this post, we’ll explore some ways to articulate the organizational benefits of ECM that are compelling to the C-level decision makers who must ultimately approve and support an ECM initiative.
When I ask clients to list the benefits of ECM, they are quick to point out the softer ones: “people will spend less time looking for documents,” “having one version of a document will mean less rework or lost work,” “we’ll spend less time mired down in managing our emails,” and so on. However true these may be, and however painfully CXOs may be aware of (and suffer from) them, they aren’t enough by themselves to justify ECM spend, at least not 2009-2010.
There are other categories of ECM benefits, however, that offer much more tangible benefits to an organization. In my practice, once the project team realizes they must go beyond soft, net-to-productivity type benefits to gain funding for their initiative, I stress four areas of general ECM benefits that are good starting points to find ROI at most medium to large firms.
No one cares about ECM (Part 1)
“No one cares about ECM” is something I find myself saying a lot these days to clients, and although it always elicits laughter, I say it earnestly. Of course it’s not true of the project team—after all, they’re spending a lot of time and money to improve how content is managed at their organization. However, in terms of the larger organizational context—the C-level folks who will ultimately pay the bill for a successful ECM program—there’s little else they could actually care less about (except maybe records management, which is a good follow up joke to the previous one).
A collaborative approach to IT leadership (Part 3)
Originally posted 7/1/2008
In the last two posts, we looked at how a collaborative approach might contribute to the effectiveness of the first 90 days of a new head of technology’s tenure. In this post, we’ll focus on how such an approach can be leveraged beyond the first three months, with particular attention to the use of three kinds of teams (leadership, management, and operations) to structure IT activity.
The head of technology has a few basic things that must be accomplished to stay employed:
1. Keep the lights on (sometimes referred to as supply)
2. Deliver requests for work on time, in budget, and to the satisfaction of all stakeholders
3. Provide leadership to the organization about new ways to use technology to achieve business goals (sometimes referred to as demand)
Each of these requires a different mix of strategy and tactics, as well as attention to both operational and managerial dimensions. It’s therefore imperative to make sure that the collaborative model put in place encourages all of these to be considered (albeit in different proportions) when addressing each of the above three tasks.
A collaborative approach to IT leadership (Part 2)
Originally posted on 6/24/2008
In the last post, I began sketching the context for the development of a collaborative approach to IT leadership, taking as my starting point the challenges faced by a newly-hired head of a large technology organization. I want to pick up here where I left off: laying out the framework for addressing those challenges with a unified approach to winning the support of executive leadership, developing the current state, future state, and roadmap, and winning the support of IT. But first, a little recap from last time.
Social computing poll (Part 1)
A collaborative approach to IT leadership (Part 1)
Originally posted on 6/19/2008
I’ve been doing some work on organizational architecture lately, and a good deal of what I’ve read deals with moving beyond the traditional CEO-COO structure to create a more collaborative, team-based approach to the C-level. Lots of folks have posited the need for some kind of executive team or leadership committee to replace the CEO-COO team, but I haven’t (yet) found a treatment that has the right blend of strategic and tactical advice for organizations looking for a collaborative model of executive leadership. Until I do, I’ve been trying my own hand at building a model based on my experiences living through a number of organizational leadership shifts.
And rather than tackle the problem from the enterprise level, I wanted to begin a bit smaller to get started and test my ideas out, taking the example of how a newly-hired head of a large technology organization might go about fostering collaborative leadership in their department.
The newly-hired head of a large technology group has a few key goals to achieve in the first 60-90 days (other than keeping the lights on, of course):
1. Win the support of the executive leadership of the organization
2. Win the support of IT leadership
3. Win the support of IT management
4. Win the support of IT non-managers
5. Develop an accurate understanding of the current state of the larger organization, IT, and the relation between them
6. Develop a future state vision of where the larger organization, IT, and the relation between them need to go
7. Develop a road map detailing how and when they will get there
Just about all the new CTOs, CIOs, and EVPs I’ve watched tackle these tend to group this list into three buckets and prioritize them as follows:
1. Win the support of the executive leadership of the organization
2. Develop current state, future state, and road map
3. Win the support of IT leadership, IT management, and IT non-managers
The thinking behind this, I imagine, is something like the following:
– If the executive leadership does not offer their support, the head of technology is dead in the water.
– If the current state, future state, and road map are not a success, executive leadership will withdraw their support, and the head of technology is dead in the water.
– If executive leadership is on board and the current state, future state, and road map are successful, the IT organization will tend to support the head of technology–and if they don’t, then the next 30, 60, 90 days can be focused on getting their support.
Based on this thinking, most leaders tackle winning over the executive team and developing their current state, future state, and road map by themselves: after all, their neck is on the chopping block for these tasks and they’ve been empowered to run the department as they think best. In some cases, they might bring in a past colleague or two as allies to help them, but that’s all.
There are a number of problems with this approach.
1. It establishes a culture of top down leadership, the effects of which are difficult to undo once the new technology head turns to the task of winning over the IT department.
2. It isolates the head of technology from IT executive leadership.
3. It increases the likelihood of making uninformed or impractical recommendations to executive leadership.
I imagine most IT folks have experienced the effects of these problems:
IT Leadership
– Feels left out as the new technology head gets a large amount of face time with executive leadership
– Feels out of the loop as the new technology head works on plans for the department in isolation
– Wonders what their role will be now that “ringers” are being brought in from outside
IT Management
– Takes their cues from their bosses, who are communicating (directly or indirectly) their reservations about the new technology head
– Wonders how the new technology head will understand the department well enough to make recommendations, since the people who actually do the work seem not to be involved
IT Non-managers
– Take their cues from their bosses, who are communicating (directly or indirectly) their reservations about the new technology head
– Wonder how the new technology head will understand the department well enough to make recommendations, since the people who actually do the work seem not to be involved
One potential way to sidestep some of this might be to take a unified approach to winning the support of executive leadership, developing the current state, future state, and road map, and winning the support of IT. That is, to view these as parallel activities in a single process all contributing to the ultimate goal of establishing the new technology leader successfully in their job.
In the next entry, I’ll present my first stab at an alternate approach for a technology leader’s first 60-90 days.
agile ramblings 