Monthly Archives: May 2012

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.

May 18

Information Risk Management

Posted on by

The article below is part of the overall discussion of the IT organization and was written by an Executive Summary contributor, Rodrigo Ruiz.  Rodrigo was the VP of Risk Management for ING Latin America and one of the broadest thinkers I’ve run across on the subject of Risk Management.  I hope you enjoy his article and comment liberally.

I would like to share my thoughts around what is the best fit for the Information Risk Management (IRM) function reporting line within an Organization and, hopefully, get feedback from this audience.

Of course, there is no a unique (magic) recipe. In my opinion, it will depend on the size, complexity, risk profile, and regulatiory environment that apply to the business that the Company supports. In smaller and less complex Companies, I have seen the IRM function either non-existing or built within the IT Organization, or in some cases mixed with Information Security Operations function. While in large and complex Companies the IRM function is separated from IT and reports to the Chief Risk Officer (CRO) or to the Chief Financial Officer (CFO).

In Companies that have a matured Risk Management practice, IRM fits within a larger Risk Organization that combines IT Risk with all other Operational Risk functions (like fraud risk, personal and physical security risk, control risk, processing risk, compliance risk, etc) on a more integrated approach.

Usually known as Enterprise Risk Management (ERM), this framework will integrate all Risk Management functions. The Enterprise Risk Management COSO framework (shown below) emphasizes the importance of identifying and managing risks across the enterprise. The COSO framework consists of eight components:

Enterprise Risk Management

Enterprise Risk Management Model

1. Internal control environment
2. Objective setting
3. Event identification
4. Risk assessment
5. Risk response
6. Control activities
7. Information and communication
8. Monitoring.

 

Based on my experience, when a Company moves the IRM Function out of IT, it gains transparency on risk identification and reporting; therefore, making the risk more visible to the Business. IRM, in conjunction with IT, helps the Business Leaders to better understand the business risks associated to specific IT related vulnerabilities, threats, controls effectives issues, etc., so that that business decisions can be made regarding risk acceptance, mitigation, transfer or avoidance.

Please feel free to provide comments or open discussion points.

Rodrigo Ruiz

 

May 14

Framing the Problem…

Posted on by

There are a lot of frameworks out there: ITIL, CMMi, PMP, TOGAF, Six Sigma, and a couple dozen more.   Do any of them work?  Do they add more value than the effort to implement them?  I have seen companies adopt them thinking they are a panacea to solve their organizational problems, and other companies avoid them as if they would rather catch the Bubonic Plague than implement a framework.  Today, I am going to take a break from my ever-growing series on organizational structures and talk about the benefits of a framework.

“The Benefits of a Framework” is a good starting place because it really does not matter which framework you try.  Nor does it truly matter how “complete” the implementation is.  Purity is not beneficial in this case.  If you are starting from zero, and go about it with the right attitude, ITIL will be just as transformative to the organization as Six Sigma – and they could not be more different.  Which one will be easier to implement?  Which one will give you more value?  The framework cannot answer that question.  Only the implementing champion can.

This means that the critical key to the success of implementing a framework and the majority of the benefit the organization will achieve lies in the decision of who will champion the effort.  It is that person’s attitude, vision, and ability to rally support around that vision which determines success.  It is ironic that the principle of the framework (every one of them) is to move away from reliance on the organizational hero, yet the implementation depends exactly on that hero.

So what are you looking for in that champion?  First, and foremost, their conviction that the framework will solve organizational challenges and bring business value.  If they do not believe, they cannot inspire.  If they’re not focused on business value as the end-game, they will not achieve it.  If they cannot see the full scope of organizational challenges in the harsh light of day, including in their back yard, they have no ability to apply the tools to solve the problems. 

Another key characteristic is that the champion must plan their own obsolescence.  The framework is not successful if it requires personal charisma to maintain.  The hero is not only no longer needed, but an actual hindrance to eventual success.  The champion must be able to get follower momentum until it is capable of sustaining itself, then get out of the way.  It is about the organization’s success, not the champion’s personal resume or fiefdom.

Finally, the champion needs a healthy dose of realism.  What will the framework solve, and what can it not solve?  In reality, it solves nothing in the present.  It is only the way it was implemented that solves or does not solve a problem – did the implementer aim to solve the right business problem?

So if the framework doesn’t matter, and it is only the alignment of the implementation to the challenges of the business that determines the resulting value, what good is a framework anyway?  Nothing – now.  But it provides a common language with which the future can be described.  Whichever framework you choose to solve any given problem gives you a common taxonomy to ground the discussion with vendors, with potential candidates for key positions, orienting new hires and guiding the thought process of the strategic thinkers in the organization.

So, it does not matter which framework you adopt, only that you have one.  So what if it is only adopted within two groups of your organization – it provides a communication structure and it solved business problems.  This group believes in CMMi and that one believes in Lean?  Great!  Neither one solves all problems, and each has drawbacks that detract from their value which can be solved by the other.  So get the two talking to each other and see what results.  It’ll be interesting, and if it is approached with the right mindset, the offspring of that union will generate business value.  The only problem is that no one will know what to call it.

So: What are the different frameworks and where do they fit in?

Information Technology Infrastructure Library (ITIL) focuses on – in a phrase – service availability.  It defines several disciplines and organizational structures, but in the end every one of them is aimed at preventing a service disruption or restoring a service to operations as quickly as possible.  It provides one possible map for how to structure an IT Operations group and processes for managing change.  The change management is best suited to a Waterfall SDLC, but can be adapted to Agile.  The effort is typically led from the Operations side of the house, in either Risk Management or Production Operations.

Capability Maturity Model, Integrated (CMMi) focuses on process in the hope that if you get the processes right, the end result cannot help but be right.  Any failure in the result, by definition, was caused by a defect in the process.  CMMi is frequently and incorrectly thought to be the answer to software quality issues.  It is usually led from the Change Management group.

Project Management Professional (PMP) is one of the best certifications I’ve seen.  In order to achieve the certification, the candidate must have lead projects throughout the full lifecycle for at least 5 years – and that claim is randomly audited.  Most other certifications test your ability to absorb and repeat their taxonomy.  While PMP speaks in terms of process, with inputs and outputs, it truly centers on communication.  Leadership typically centers in the obvious portfolio/project management organization.

The Open Group Architecture Framework (TOGAF) derives from earlier architectural frameworks, but from what I can see it appears to be a re-cast of PMP with an architectural point of view.  While PMP focuses on communication, TOGAF centers on the artifacts.  The obvious group for this is Enterprise Architecture.

Six Sigma is all about statistical process control.  It is frequently disregarded in the IT realm because it is strongly linked conceptually to manufacturing, and of course manufacturing software is completely unlike manufacturing anything else…  The real problem with using Six Sigma in IT is that there must be sufficient statistical data points to generate a meaningful sigma.  I am lining up a guest writer to discuss how some Lean concepts such as Kanban can apply to the software development process.  This is often led by outside business units or by the Process Improvement committee in the Governance arena.

Understand that any summarization of these extensive frameworks that boils down to 3 or 4 sentences is generalized almost to the point of uselessness, but it helps to understand the “problem space” that each is intended to solve.  I do not recommend implementing any of them in their entirety, but cherry-picking the best of breed processes to solve targeted operational problems.  Has anyone experienced something that shows otherwise?  Any disagreement with the overly simplistic summaries here?  Please comment so we can all chime in.

May 11

Supporting Production Operations

Posted on by

Continuing my series on the structure of a theoretic IT organization, today’s subject is the group in Operations that supports production systems. The Production Support group’s primary function is to act as a proxy for the customer throughout the organization. Resources are limited in the company and reacting to every customer issue appearing through the help desk results in chaos – it is impossible. This organization prioritizes the organization’s response on behalf of the customer. They must determine the organizational cost of not resolving the customer’s issue and compare that to the estimate of the cost to resolve it – as expanded across the potentially affected customer base. There is no single cut-and-dried formula for this, each company must develop their own. The result of this calculation determines which issues get addressed first and how fast.

Production support also represents the customer in planning meetings and product roadmap sessions.

The people in this group must be hired for their empathy with the customer, drive to satisfy the customer’s need, and ability to quantify the business impact of customer problems. Technical skills can be learned. Customer rapport is a talent. One key set of metrics this group must understand inherently is Customer Lifetime Value (CLV), Customer Referral Value (CRV), and the Cost of Quality (CoQ). While it is important to resolve the customer’s problem and generate customer satisfaction, it must be done with the company’s long term interest (the bottom line both now and in the future) in mind.

Another consideration is that, as proxy for the customer, the Production Support organization also owns the data in the prodution databases.  This seems a strange concept – the data is not owned by the lines of business, but by the customer’s representative.  It makes more sense when you clarify that the line of business users are customers of the IT organization.  But making the internal mindset shift that says that the customers own their own data and that Production Support acts as their proxy/guardian, various decisions and thought processes become automatic.  Privacy issues resolve themselves.  SOX separations of concerns become intuitive.  Decisions like retention policies are much easier to manage.  Most importantly, the IT Operations orgaanization becomes naturally and axiomatically more customer focused.  The transformation is amazing to watch.

I have rarely seen Production Operations organizations play prominent roles in large IT organizations, and even more rarely acting as the customer’s proxy.  When used, it has been extremely powerful.  Can anyone share stories when this concept made a significant differents, for good or ill, in your organization?

May 07

Infrastructure Operations

Posted on by

In an earlier post, I mentioned the need for an inspired leader in Infrastructure Operations because otherwise, the job can feel meaningless, unrewarding, or like you have a constant target on your back.  But I never defined “inspIred leader”.

In this environment, the first thing the leader needs to convey to the team is: “I’ve got your back.”  The leader should ensure that all blame, recriminations, or negativity in any form is directed at them, not at anyone on their team.  The only person allowed to criticize a member of the team is the leader.  This level of trust is necessary to prevent the team members being defensive and risk-averse when working with the rest of the organization.  Credit flows through the leader to the team, blame stops at the leader.

The second key characteristic for the leader of this organization is praise.  These folks hear nothing but complaints and what has gone wrong.  They need an “atta-boy” from time to time to offset the bunker mentality that could set in.  It is good practice in any environment, but these little things return even more in terms of commitment in a group such as infrastructure operations.

It is all too easy to fall into a routine that does not advance the company’s strategic capabilities – surrender to monotony.  The leader must constantly loook for small projects that provide incremental movement toward corporate or departmental goal lines because it is rare that the group will have time available for large projects.

Finally, developing an accountability program around metrics that mean something to the business, not just to IO, instills discipline and enhances focus.  Measuring packet loss around the network, or database transactions, may be easy and interesting to some, but it means nothing to the business. Reducing the latency of a small transaction that is done 100M times a day by a half-second can really be interesting to the business – especially if it is a critical business process or a prerequisite for one.

Do you have some good suggestions for metrics or motivators for Infrastructure Operations?  Please share, we could all use them.

May 03

Governing IT

Posted on by

Unlike the Development and Operations organizations, Governance is a functional role, not a position.  People throughout the IT organization perform governance roles. The Governance organization is little more than a collection of committees. 

The most obvious and common of the committees is the Change Advisory Board (CAB) responsible for approving the changes to production systems.  This group should be led by Release Management and include the proposers of changes along with those impacted by the change.  Typically, the group has a set of fixed members from infrastructure and PMO along with temporary invitees reflecting the drivers for the change and the other affected parties.

The Enterprise Architecture Oversight Committee (EAOC) is lead by the chief architect or CTO and includes the leadership of all development and infrastructure groups.  This group is charged with maintaining the list of approved/acceptable technologies within the company and vets any proposed new technology – ensuring that they are both supportable and support the strategic direction of the company.

Another governance group is the Process Improvement Committee (PIC).  This team is responsible for defining, producing, and responding to all IT performance metrics for Development and Infrastructure, using this information to define Service Level Agreements and Operating Level Agreements (SLA/OLA) and any process improvement initiatives.  This is the natural home for Six Sigma methodologies and projects (Yes, Six Sigma can be applied to IT).  Once identified, process improvement projects are passed to the Portfolio Management group.

The Project Governance group (PG), led by the head of the Project Management group, arbitrates all project conflicts ensuring that projects are prioritized and resourced at the company level.  Another key function of this team is to spot when one silo within the business is taking action that will either conflict with or potentially enhance the operations of another.  Significant project timeline and cost risks are directed at this group for resolution or mitigation.  Out of this resolution, problems requiring Process Improvement focus will be surfaced and referred to PIC.

The final committee in the Governance arena is the Strategic Planning Committee (SP).  This might be chaired by either or both of the CTO and the leader of Portfolio Management.  The group uses the roadmaps of all the business units and corporate executives as input to define the IT roadmap for the next 2 years, adjusted at each quarterly meeting.