Category Archives: Strategy

Jun 11

Strategic IT Resource Allocation

Posted on by

So, now that I have pontificated for about 6 weeks on IT organizational structure, I can finally answer the Professor’s question: how do you strategically allocate people to keep normal operations flowing yet still advance strategic IT capabilities that extend the business’ competitive advantage?  If you put all your attention on keeping current things from falling apart, the competition will pass you by.  If you focus only on the future, the floor will rot out from under you – that was the essense of the conundrum he presented (rephrased in my own words).  So: where do you put your best people in order to keep both progressing?

The obvious and over-simplified answer is to balance it out so that they’re spread across the organization.  But I contend that beyond being trite, it is also wrong.  First, the two areas require different talents, meaning it is not an either-or situation.  Second, there are different levels (individual contributors, first-level management, executive direction) that provide more levers to push.  I think that the U.S. Navy has long had the general answer to this question.

A ship is run 24 hours a day, separated into watches.  Let’s divorce theory from reality for this discussion and say that there are 3 watches, one led by the CO (Captain), one by the XO (first officer), and one by the CDO (command duty officer, which is a rotating role, not a person).  Who is on the bridge with the captain?  The weakest, newest officers being evaluated or trained into the positions.  Who is on with the weakest of the three commanding officers?  The best officers for each position – specifically to cover the weakness of the officer commanding the watch.  We’ll ignore the mix characteristics for the XO for the time being.

This same model can act as a guide in strategic personnel assignment.  In the maintenance role, you want a tactical leader who is a great crisis manager.  This role needs little strategic thinking, other than planning for the next crisis.  The people they lead need dogged troubleshooting skills and deep knowledge of how things work, but they do not need to be the “best and the brightest.”  The senior leadership of this group performs mostly an administrative role.  Of the three levels (IC, mid-management, executive), the maintenance/operations group needs the mid-management to be its strongest link.

The development organization, on the other hand, is the exact opposite.  The individual contributors need to be independent and creative, the best and the brightest.  Mid-managers in development often only need resource-management or administrative skills – if the individual contributors are as strong as they should be.  The executive level needs strong vision and inspiration ability.  In this case, the stronger people are in the Individual contributor and Executive positions, while mid-management can be weaker.

Those who show strong management potential might be promoted into mid-management of the maintenance organization where they gain knowledge of how the business works, how important it is that things keep operating, and how to deal with high-stress situations.  Managers from the maintenance side of the house can make good candidates for the executive core of the development organization because they now understand more of how the whole business works and what they need to work better.

As with any organization, there is no one cookie-cutter approach that works all the time.  What I describe here works when the IT organization is structured as I described in the past several articles.  The same kind of thinking (why you need strength at different levels) applied to IT Organizations with different structures and strengths will lead to an optimal layering of talent for that specific organization.

Tell us all how your organization focuses its technical talent to achieve organizational objectives.  Have you seen models that work better?

Jun 07

IT’s Batman and Robin

Posted on by

So we have two TLA’s (Three Letter Acronyms) that look alike and sound alike, what is the difference between a Chief Information Officer (CIO) and a Chief Technology Officer (CTO)?  I will give you a different answer and prospective than you will see by Googling the terms.  The difference is very simple: Whatever the two of them decide it should be.

Sure there are standard definitions, but they should only serve as guidelines.  An organization is unlikely to find two people that fit the textbook roles and they should not try.  The two need many overlapping talents – vision for the future, ability to truly see the present, a deep understanding of the business and industry, and the ability to lead and inspire their people.

I have seen many pairings in different shapes and flavors.  One organization had the CTO as a peer of the CIO, where the CTO (with no direct reports) reported to the CEO and the CIO reported to the COO.  In some, the CTO is little more than the “idea man” for the development organization.  Most common is the CTO who manages the Enterprise Architecture group.  The textbook-ideal has the CIO doing hands-on management of the Operations organization, and managing the Development organization through his proxy, the CTO.

The structure does not really matter as long as it supports the natural division of talents between the CIO and the CTO.  They are partners in helping the business drive for success.  For example, while the CIO would typically be responsible for the supply chain, if the CTO has a very strong LEAN background, they may swap that role.  The two should split up the responsibilities for the department based on which one can best do each major task.

Speaking in generalities, however, the basic distinction is that the CIO focuses more on current operations and efficiencies, while the CTO focuses more on growing the catalog of business capabilities.  Within that very high level division of interest, the two of them operate as a team filling in all the holes and driving excellence into the business.

I have seen a new definition pop up lately, the Chief Science Officer (and every time I hear it, I think of Spock – smile).  Has anyone ever seen such a role in their organization?  How did it compare to CTO and CIO, and did it make an operational difference to the organization?  Please comment here and let us all know.

May 29

Understanding what the business needs

Posted on by

The last installment in my series about IT Organization will discuss the PMO. What does that stand for? Most often, Project Management Office, but some call it Program, others Portfolio, and though the words have different meanings which affect the focus, they all boil down to one thing: Understanding what the business needs, prioritizing it, and getting the organization’s resources behind getting it done.

The PMO’s first task is to understand what the business needs. Portfolio management is the best starting point. The portfolio managers are linked to lines of business and understand their roadmaps. This can be done by pairing portfolio managers with product managers in the business units, if they have them. Since the business units have more work than can be done at once, the portfolio manager also provides prioritization of strategic portfolio work as well as projects and maintenance work (where the line of business has reported bugs or requested minor enhancements not sufficient to group into a project). The portfolio manager must understand all work streams for their line of business and organize the work streams to fit the amount of time IT management allocates to that line of business.

Program managers are typically assigned one-to-a-program where the scope of work is strategic and large – to the point that the program manager may have a project manager or two working for them. Project managers will typically work on more than one project at a time, providing project management shared services to the enterprise. Project and Program managers should be certified by the Project Management Institute (PMI). Of all the certifications I have taken or seen, this is the most meaningful. It requires the candidate not only to be able to recite their taxonomy, but also to demonstrate several years of experience actually doing the job.

The second segment of the PMO is the Systems Analysts and Business Analysts. This group is the font of knowledge of what capabilities the business has. These analysts elicit requirements from the business users and translate them into specifications for the developers. They become the experts on the details of what must be done, and work in conjunction with the subject matter experts and architects to figure out the ‘how.’ The strength of the analysis group allows the development group to become centers of excellence for their technologies rather than silos aligned to the business units.

The head of the PMO is the natural leader for the Project Governance group, but a key characteristic that must be sought in this position is the balance between delivering when needed and following the process. It is too easy for the leader to get caught up in making the process king and becoming a bottleneck in achieving the business’ strategic goals.

I watched an organization struggle trying to make their PMO fit this vision, but left before it was implemented. The difficulty they had was getting sufficient knowledge of the business in their Business/Systems analysts, when starting from the ground up. Does anyone have any suggestions for how to accomplish this?

May 22

Do Enterprise Architects Architect the Enterprise?

Posted on by

In a word, unlikely. 

Today, I continue the series on IT organizational structure.  So far, I’ve talked about Operations (with three sub-areas: Infrastructure, Production Operations, and Risk Management) and Development.  Today’s topic is Enterprise Architecture, and it will be natural along the way to discuss the Enterprise Architecture Oversight Committee (from the article on Governance).  The final article in the series will be Portfolio Management and two related Governance committees: Project Governance and Strategic Planning.

So: Why don’t Enterprise Architects Architect the Enterprise?  Because almost always, the Enterprise is already built (smile).  At best, they’re blueprinting the remodeling effort.  Unfortunately, in too many cases, they’re re-arranging the nick-nacks on the shelves.  The challenge for the leader is to keep the organization relevant by solving business problems without resorting to ivory tower ideology.

Today, everyone calls themselves an architect.  Apparently, development and analysis titles are too boring or do not pay enough.  Anyone who can string three programs together is an architect.  For the purposes of the Enterprise Architecture group, I plan to focus on four types of architects: Application (domain expert), Solution (cross-application focus on single business problem), Infrastructure (hardware), and Enterprise – along with their boss, the Chief Technology Officer.

An Application Architect focuses on a single (or a few related) application domains (Provisioning or Fulfillment are examples).  This role is a subject matter expert in the business domain.  The individual has knowledge of all the technology used to solve the problem space – applications, servers, databases, middleware, hardware and business processes.  Application Architecture strongly overlaps with the Portfolio Management Systems Analysts for that business area so that you can use the strengths in one to manage the weaknesses of the other.  This area also includes the architect responsible for the middleware layer (e.g. Enterprise Service Bus, Business Process Modeling, etc. – sometimes referred to as a Technical Architect).

A Solutions Architect takes a single business problem from idea to reality across all applications and infrastructure.  Solution Architects often overlap with Project Managers.  They lead cross-functional teams and do joint design sessions, integration walkthroughs, etc.  The Solution Architect is a guided missile who is aimed at the target of the strategic business problem to be solved and who brings every resource necessary to bear on the problem until it is solved.

The infrastructure architect is busily trying to figure out the best configuration of hardware elements will most effectively support all the needs of the enterprise. Many organizations place this responsibility in the Infrastructure Operations organization, but it truly belongs in EA.  This role is responsible for everything from the composition of the data center, integrating cloud processes (internal and external), to what type of equipment goes into the networking closets at all the remote offices.

The Chief Technology Officer is the leader of this organization, whether tasked with management responsibilities or not.  In some cases, the CTO has incredible talent to solve massive strategic business problems between breaths, but would drive all the design talent screaming out of the organization.  While this is regrettable, sometimes the talent is too strong to give up and must be supplemented by a manager to take day to day supervision tasks off that person’s shoulders.  But even in that case, the CTO sets the direction for the EA group by defining the right problems to solve and the principles to which the group will aspire to in solving them (principles based architecture).  It is best if the CTO directly leads the group, but even if that is not feasible, the CTO is the spiritual leader of the team.

Shortly, I plan to discuss the differences between the CIO and the CTO.  The two are like a matched pair complementing each other’s weaknesses with their strengths. The compatibility of the CIO and the CTO is far more important than the actual job definitions for each, as they can fluctuate to take advantage of each one’s superior skill set.  But I will talk about what the roles should be in theory.

The CTO is the chair of the Enterprise Architecture Oversight Committee (EAOC) in the governance role.  Does that mean that the CTO is dictating architectural decisions to the rest of the organization?  If so, that person should not be the CTO.  The EAOC decides issues by consensus, and the CTO is the chief salesman within the group, advocating for the vision.  If the CTO cannot convince the operating majority of the group, it is likely that the idea is not good enough or the CTO lacks persuasive ability, which is a key component of the job description.  As described earlier, the EAOC is charged with maintaining the list of approved technologies and ensuring that any newly proposed technology or major architectural component has been fully vetted before being acquired.

One organization used the EAOC to enforce its technological will on the development directors (because the leader was dominated by the “bright shiny object” syndrome – adopting technology simply because it is “cool”) or as constraining leash on the architecture group (because it was lead by the risk-averse Operations group).  Properly run, it is balanced and focused only on what is healthy for the whole enterprise.

Please share your stories of how EA helped or hindered your organization in the quest for strategic growth.

Apr 30

The Strategy of Development

Posted on by

As part of the series discussing potential organizational strucutres for IT, the Development organization must be understood as a strategic partner to the business.  One way to think about it is that Operations is focused on the immediacy of today while Development drives the effectiveness of tomorrow. Development keeps the business in tune with the market and the company’s future direction.

Superficially, this can make it sound like Development is simpler to manage than Operations, but it requires a different mindset than found in many Development organizations.  Many either isolate the developers from the business (to keep them focused on that all-important code), others fracture the development staff so that they are almost part of the lines of business and are ultimately reactive.  In my view, developers should be organized into functional groups that either support each line of business (silos) or by technology (such as a Mobile Applications group and a Portals group).  Each has its benefits (discussed below).

How does this not fall into the two traps I mentioned?  By adding a Portfolio Management Office function.  The weaker the PMO, the more strongly aligned to the business the development organization needs to be.  With a true center of excellence in portfolio management, the development silos can break down and become technology centers of excellence.

Chart of Organizational Structure

Potential IT Org chart

My diagram shows Portfolio, Program, and Project management.  So, just what is the distinction?  Project and Program management is fairly commonly understood – the simplest definition of a program is a series of projects.  But it has been (well) said that the distinction between Project/Program management and Portfolio Management is the difference between doing things right and doing the right things.   The PMO also contains Business and Systems Analysts who drive the acquisition of requirements from the business units.  There will be more in a later post that I will devote to the PMO.

Enterprise Architecture is what prevents the rest of the development groups from devolving into silos and fiefdoms.  This group drives down the accumulation of technology debt by preventing bad decisions, promotes reuse and modular architecture, and ensures that systems have broad use across the enterprise rather than serving the needs of a narrow constituency.

A word on frameworks at this stage.  Just as Operations is the “home” of ITIL, CMMi, and Six Sigma, Development is the home of PMI’s framework (in the PMO) and TOGAF (in Enterprise Architecture).  More on this later as well.

An obvious question at this point: Agile or Waterfall?  This post is already too long so I will address that in another post.  Purists will be disappointed.

Let me pose a question to the audience: Should the development staff be organized along lines of business as subject matter experts, or by technology competency so they provide shared expert services across the business?  Conceptually, I favor the latter, though I have only seen it work properly in software development companies where they produce software for sale.  In that case, technological talent is more important than deep subject matter expertise – it is the designers who must understand the business, not the developers.  Is it impossible to use this model where IT supports the main function of the business and is not producing the product for resale?