My recent post on Shadow IT: The Good , The Bad and The Ugly solicited an interesting comment about organization design and the placement of application development versus application support. This got me thinking back over years (probably 25!) of helping clients with IT organizational design, and the tools, techniques and principles I’ve used over the years. I thought it might be worth sharing these, and perhaps engaging in some interesting global conversations.
Let me start with a couple of overarching principles I’ve tried to keep in mind when designing IT organizations.
- Share (and make common) everything that can be shared. Implications include: resource pooling is better than permanently attaching individuals to applications, which tends to foster an endless string of low value enhancements, good for job security but not necessarily for business value or innovations! Enabling capabilities such as Enterprise Architecture, Global Sourcing and Organization management are almost always great candidates for being globally common and shared.
- Don’t share things that should not be shared! I realize this is a weak principle (according to the principles of principles!) and a corollary to principle 1, but I think it’s important to state. Some things are better not shared – they are unique to a business unit or function, there’s no leverage in sharing them, and sharing them will compromise quality or service (lowest common denominator).
Let me move on to a couple of models or lenses that I work with my clients to look through at IT capabilities. The first is an oldie but goodie – the Value Disciplines from Tracy and Wiersema’s Discipline of Market Leaders. The authors describe three distinct value disciplines – Operational Excellence, Customer Intimacy and Product Leadership. They argue that while any company has to be good at all three, operating models tend to optimize for one of the disciplines. Not everyone buys this argument, and like all generalizations, there are some limitations to the assertion, but by and large, I’ve found the lens to be invaluable over the years. Let’s look at the disciplines:
- Operational excellence means providing customers with reliable products or services at competitive prices and delivered with minimal difficulty or inconvenience
- Customer intimacy means segmenting and targeting markets precisely and then tailoring offerings to match exactly the demands of those niches. Companies that excel in customer intimacy combine detailed customer knowledge with operational flexibility so they can respond quickly to almost any need, from customizing a product to fulfilling special requests
- Product leadership means a focus on product innovation, offering products that push performance boundaries
Translating this into the world of IT, it is clear that IT organizations have to embody all 3 disciplines. It is also interesting to note that climbing the business-IT maturity model tends to focus on the Operation Excellence needs first (IT infrastructure), then on the Customer Intimacy pieces (business processes and applications) and finally on Product Leadership (business innovation through IT).
IT operations (data centers, telecommunications, help-desks, etc.) lend themselves to an operational excellence model. That is why frameworks such as ITIL can be so useful. Discovery of IT-enabled opportunities is inherently a customer intimacy play – which is why this function is often best embedded in the business – logically and physically. I believe that Enterprise Architecture and advanced technology research and development are essential a product leadership play, and these work best with a central focus (perhaps a competency center, community of practice or center of expertise – terms that get used in many different ways) coordinating a distributed network. For example, an Architecture Center of Expertise owns the role of defining standards and enterprise-level models, but works through a network of business and technical architects (roles, not necessarily full time jobs) distributed throughout the enterprise.
This is turning into a longer post than I like, so I will stop there but follow up with a post on another organizational design framework I’ve found very helpful – one that comes from Henry Mintzberg.