Program Management Dominos

How many times have IT organizations spoken about application rationalization or infrastructure refreshes? Over time many solutions have been created to solve the issue of the day or take the business in a different direction. Once created these applications never die, hence the application rationalization program. And once in place, refreshing the infrastructure becomes a challenge since you don’t know if the existing application will run on the new hardware or version of the operating system. But I have often heard these two discussions being held independently without concern to the impacts of one upon the other or more importantly the business implications.

What about the strategic planning process and the resulting action plans and allocation of resources? How often are the dependencies between the strategies addressed in order to make the action plans actionable?  I have often seen the strategies split between different executives to deliver without understanding the interdependencies; often resulting in increased costs, unnecessary issues down the road or complete failure of the strategy.

In my mind, this is one of the differences between projects and programs.  Programs ensure that the interdependencies are recognized; that the dominos are set up so they fall down in the right order. 

I remember one really effective yearly planning process.  We covered a wall with the outline of a Gantt chart with the strategies and associated 70+ candidate projects down the left side, each with an estimated duration and start date.  Then each functional group was given a different color of small post-its.  For each project, each function put a post-it in every month where their organization would be required to participate.  Talk about being able to visually see resource contention!  It also generated a lot of questioning and discussion to really understand what each project was trying to accomplish.  This caused some projects to be combined and identified dependencies which generated start date and duration changes.  This planning process yielded a set of seven programs, all of which were successfully delivered that year; the right dominos got selected, set up in the right places and were knocked over with precision!

Something similar happened with an infrastructure refresh program.  Based on business need as to which applications were not meeting performance requirements, a set of applications were identified for refresh (the throw more hardware at it approach).  Matched to this was the set of outstanding requests against each application, its part in the business process flow and any existing upstream or downstream projects.   As a function of this, each was evaluated for refresh, upgrade, replacement or retirement.  By setting up the dominos in this order we were able to create a program that was business driven and accomplished both application rationalization and infrastructure refresh.

How have you been setting up your program dominos?

© Ellen Terwilliger 2012

Big Data-OK; Master Data Management–Yes; Critical Data Leverage–Absolutely!

This world of big data and analytics has somewhat overshadowed the data foundation that makes organizations run. Even the concepts of Master Data Management (MDM) and Data Governance sometimes mask the base that lies at the heart of doing business. Consider the following two scenarios:

Program 1 – Master Data Management (MDM)

A group of people from each functional area was brought together to determine the data needed to understand their business. Each was concerned that the data they cared most about was included in the data governance and maintenance process. While the group defined the core data elements that would tie all their individual pieces together, their main focus was to ensure that they could get the reporting that they wanted to run their function. The end result was a heavily attributed master data hub surrounded by complex integrations that was easily accessed and centrally maintained by the data stewards from each function. The data was then supplied (duplicated and/or transformed) to the reporting and analytics engines to deliver to the reporting requirements of each individual function and ultimately the needs of the corporation as a whole. This was more of a metrics/KPI /reporting based approach.

Program 2 – Critical Data Leverage (CDL)

A group of people from each functional area associated with the end-to-end business processes was brought together to determine the data attributes that drove the behavior of the company’s business. They were concerned that their company presented a consistent face to their customers at all times while managing their job functions. These people discussed (argued even) about the data used to segment customers, group offerings, drive the go-to-market strategy, determine geographical differences and so on. The end result was a small data steward team that governed the core data for the company as a whole. They managed the master data hub that integrated that core data to all consuming applications and the reporting and analytics engines. Each of the functions delivered their own reporting and fed the analytics engines to meet the needs of the corporation as a whole. This was more of an operations based approach.

Each of these approaches delivered the data foundation to tie the functions of the organization together and enable reporting and analytics. I have participated on programs that have used each of these approaches and I believe that critical data leverage comes first and master data management follows. In my experience the groups who used the critical data leverage approach created a more flexible and scalable foundation for their company to grow on and met their functional requirements as well. The metrics and KPIs came out of the operational model as opposed to the KPIs driving the operational requirements. Be careful what you measure, because that is what you will get; better perhaps to know where you’re going before determining how to measure if you got there (this kind of resembles the system integration cart being before the transformation horse ). At the core, know what data drives your organization.

Even with analytics, big data and the desire to discover unknown patterns, it is still important to have a purpose behind the quest. There is a difference between data, information, knowledge, understanding and wisdom. What you’re looking for is wisdom to make better decisions; big data is a method to provide you some understanding based on the knowledge of the information and data that’s out there. The question is what do you want to be wise about?

Maybe we should be talking about Critical Data Leverage, Master Information Management and Big Knowledge.

© Ellen Terwilliger 2012

Is your System Integration cart before your Transformation horse?

I was having discussions with some colleagues who are participating in transformation programs at their respective companies.  Each program is segmented in two; one part focused on business transformation led by one outside partner, the second on systems integration led by a different partner. 

The question: What approach should be used to ensure you get the best possible outcome for your company?  I suggest you get your dancing shoes on because you will be balancing on a fine line.  First it would be good to know what style dance and song you are going to dance to before you begin.   A lot of work was done before these partners were selected; I am sure there was a business case, budget projections, etc.  But is it clear if this is primarily a business transformation or systems implementation program?  These can be very different with very different outcomes, even though many of the areas addressed may be the same: business requirements, process flows and taxonomies.  The difference is where you start and who plays what role along the way.

A business transformation according to businessdictionary.com is a process of profound and radical change that takes a business in a new direction and entirely different level of effectiveness, a basic change of character with little or no resemblance with the past configuration or structure.  Unless it’s a startup (which wouldn’t need to transform anyway), there are already organization structures and go-to-market strategies in place.  But something has happened that makes the company believe that it needs to change and somewhat significantly to be competitive.  Does your program clearly know why the need to transform exists and what your executive sponsors believe success looks like?  This is the role of the business transformation partner:  to articulate why to transform and what to transform: business models, operational models, business process flows and organization structures.  It’s often in the business process flows where the transformation horse and the integration cart get sideways.

Let’s back up for a moment though.  What is the systems integrators role?  If why and what are the transformational piece; then how to map the models and process into technology solutions is the systems integrations piece.  This will be affected by both the application landscape currently in place and by total cost of ownership (vanilla or custom, fit for function, cloud based, etc.) The “how” is focused on technology, balanced with process and guided by transformation.


This is where the dancers can step on each other’s toes. Both the transformation and integration partners have input into the business requirements and process areas and need to work together. Dare I say it; a RASCI is probably required in order to define who does what. It is likely this was not done initially when the partners were selected because that was too deep of a level of detail at the time. More important though, your company has to define how to make decisions between model, process and technology tradeoffs. Your organization’s magnitude of transformation, appetite for differentiation and budget will all play a part in establishing these guiding principles; this is the balance on the fine line. These tradeoff guiding principles will help to define the responsibilities of the transformation and integration roles and make decision making more rapid all along the way.

 It is essential that the transformation horse is ahead of the system integration cart.  Without consensus on why and what (the horse), your program will not know the style of the dance.  And without the tradeoff guiding principles (the reins), you won’t know the song to dance to.  Both of these are necessary to determine how (the cart) to dance your dance.

I may have mixed a couple of metaphors, but I hope you can see that the transformation (why and what) should be clearly defined before bringing in systems integration (how) and determining the right balance of differentiation and total cost of ownership for your company.

© Ellen Terwilliger 2012

CIO of the Cloud (or not)

Chief Information Officer is an interesting title; what is the CIO accountable for?   Here’s a definition from Gartner:

CIO (Chief Information Officer)

The person responsible for planning, choosing, buying and installing a company’s computer and information-processing operation. Originally called data-processing managers, then management information system (MIS) directors, CIOs develop the information technology (IT) vision for the company. They oversee the development of corporate standards, technology architecture, technology evaluation and transfer; sponsor the business technology planning process; manage client relations; align IT with the business; and develop IT financial management systems. They also oversee plans to reinvest in the IT infrastructure, as well as in business and technology professionals. They are responsible for leading the development of an IT governance framework that will define the working relationships and sharing of IT components among various IT groups within the corporation.

That’s pretty encompassing and I think accurately describes what I call “Enterprise IT”, or what it takes to help your business run efficiently and effectively from an internal perspective.  But what happens when your business is the business of technology?  What if your revenues are based on a cloud offering?  It’s one thing if internal operations are compromised, but it’s a whole different level if your livelihood is on the line.  This situation can still be considered your company’s computer and information-processing operations and the domain of the CIO.  However, product development and perhaps the CTO have some pretty big influence on the technology architecture; in fact they probably own those standards and decisions.  So what’s a CIO to do?   

That’s where “Cloud IT” and being CIO of the Cloud comes into play.  While the CIO may have little to say about what’s running, they may have a lot to say about how it runs.  There is still no one better equipped to understand the operational and support aspects of running IT.  And the truth of the matter is; the product people aren’t so interested in running the cloud as they are in creating the cloud.  By the way, the Gartner definition sort of neglects the operational and support aspects of the CIO role since they stopped at install.  Here is where the CIO must align IT not with “the business” as in the Gartner definition, but with the “business of the business”.  They know the IT professionals and processes it takes to run technology, the CIO should be the partner entrusted with running revenue operations. 

Are the Cloud CIO and the Enterprise CIO the same person?  I remember one time when the company I was working for was acquired, the network was being run by the product development organization.  You never knew what was going to happen when you plugged into the wall (this was a while ago obviously), would there be connectivity or not?  There is definitely segregation required between Cloud and Enterprise IT, security and access are very different between the two not to mention the application set.  There are also common skills required in both aspects of the CIO role and within the organization, the focus and priorities are very different though.  Of course, not every organization is faced with this dilemma but it is becoming more prevalent as the cloud continues to evolve and grow.

What kind of CIO are you?  What kind of IT organization are you a part of?  Which one keeps you up at night?

© Ellen Terwilliger 2012

When RASCI #2321 is not enough

You know you have a program that is set up to fail when:

There are two thousand three hundred twenty one RASCIs and still no one knows what they are supposed to do and what they are not supposed to do.  And they spend all their time protecting what they think they should do and arguing with the other guy about what they should and shouldn’t be doing.

I’ve been on a program like that.  Every other day someone wanted to create yet another RASCI (if you don’t know what that is, consider yourself lucky) at yet another level of detail to attempt to take responsibility for something; or better yet to place blame on someone else for something that’s not going so well.  Needless to say, not much was getting done except to fight over who did or didn’t do what to who.

I’ve also been on a program where there were no RASCIs at all.  WHAT, not even one?  This was a program where people knew whether they were a screwdriver or a butter knife (see http://visionpeak.wordpress.com/2012/02/01/the-butter-knife-and-the-screwdriver/) and had no desire to be anything else.  Everyone was busy, contributing, and being recognized so it wasn’t necessary to worry about what the butter knife was doing; being a screwdriver was enough. Not only was it enough; it was fun!

Why do you suppose that was?  I believe it’s because every person could see in their own mind exactly where the program was headed.  And people all saw the same picture.  Everyone knew what was required to get there and what their role was (screwdriver or butter knife) in getting there.  They also believed that it took both the screwdrivers and the butter knives to get there, neither was enough alone and neither could do the other’s job near as well.  Trust was implicit.

So how did that come to be?  In this case, investment was made “up front” to create that common vision of what success looked like.  Along with that was a description of what and who was required to get there; both the screwdrivers and the butter knives.  All this, before the implementation program was even launched; there wasn’t a systems integrator in sight (or billing by the RASCI line).  For this program it wasn’t so much about how it was going to be done; it was about figuring out what to do first.

The payback?  An implementation program that was on time and under budget.

Sometimes I twitch when I hear RASCI.  Maybe you might need one RASCI, but many more than that and you’re probably headed for a program that is set up to fail.  And if you feel you need to have that one, it’s best to not have too many lines…

Don’t twitch!

© Ellen Terwilliger 2012

Anything is possible with time, money and expertise

This phase was a common answer from me when asked if our IT applications organization could do something for the business. When I first used the phrase back in 2002, it went “Anything is possible with time, money and resource”. I modified it a bit later after realizing that not all resources are created equal. If you have never done something before, there is no shame in asking for help from those with the expertise. That way you get to learn so next time you have the expertise. But it’s really not so much about what the phrase says as it is about the attitude that is represented.

I don’t know if this has ever happened to you, but in my career I have run into people who only know how to say why something can’t be done. They continually look for what won’t work, make excuses for why they don’t want to do something and generally throw up roadblocks every step of the way. For me, it’s not very much fun working with people who have that kind of attitude; everything seems to be a struggle. The easiest question can take weeks to be answered. In fact, depending on where they are in the organizational structure, an attitude of that nature can make it almost impossible to get anything done. Instead of engaging in a quest for answers, everything stops at them since they have already decided it’s never going to work.

On the other hand, if you have people who are constantly looking for how something can be made to work, I believe you have a pretty open environment. Instead of there being roadblocks, you have many people engaged in blowing holes through the rock trying to see if what’s on the other side will help. That’s how successful programs get done, because people have an attitude that it is possible.

Take a look at yourself. Are you a roadblock or a rock breaker? It is up to you the attitude you take every day. There are always down times but I fundamentally believe people want to be successful and make things work.

My mantra: anything is possible with time, money and expertise.

© Ellen Terwilliger 2012

How cloudy is your IT career?

I have heard a lot of conversations about the impact of the cloud on Information Technology (IT) careers. People are worried that the positions they hold in IT will be eliminated because “it’s in the cloud”. Even the role of the Chief Information Officer (CIO) is being questioned. Like the REM song, some IT workers are seeing the end of the world as they know it. Not all of them feel fine, but I am not so sure it’s the end of the world; I think maybe the world has just rotated a bit, so I feel fine.

Let’s start with a definition of Information Technology. Based on Merriam Webster, information technology is the technology involving the development, maintenance, and use of computer systems, software, and networks for the processing and distribution of data, where technology is defined as the practical application of knowledge especially in a particular area. Also consider the definition of engineering or the design and manufacture of complex products.

When I think of IT careers, I think of the Corporate IT department focused internally on the practical application of technology knowledge to run the applications and infrastructure that are used for the business operations of an enterprise from marketing through support. Engineering, on the other hand, is externally focused on creation of revenue generating (preferably) products offered to a targeted customer base often based on the use of computer systems, software and networks (IT). In some organizations the IT department supports engineering and sometimes it doesn’t, that is always an interesting conversation; is support of the infrastructure for Engineering an IT or an Engineering career, the activities are often quite similar and Engineering platforms are often good cloud candidates. So are IT or Engineering careers more affected by the cloud? I am not sure either, but let’s keep going.

Beyond IT support of engineering platforms as a career, there is career rotation going on from IT into Engineering. Take networking for example; it is a core competency for ensuring that clouds continue to float.

Capabilities are moving around, some things that used to be delivered in hardware are delivered in firmware and firmware in software (that’s why the word “mostly” is in the picture). But more important from an IT career perspective is the move of tasks that were done manually into software. Now instead of having an IT career in a company implementing and supporting their network you might rotate into a company developing a product that does what you used to do manually (isn’t that what technology is all about) and have an Engineering career, still technology focused just a little rotation. You can take this rotation to other information technology disciplines as well. Look at the whole concept of virtualization and the Engineering careers created from IT needs being looked at in different ways and solved through technology.

The use of the term information technology continues to become broader since computer systems, software and networks have become ubiquitous. You can be talking about the CIO and the Corporate IT department running your business (IT careers) or any aspect of technology used to run anything, anywhere, which for my purposes I am going to call Service Provider IT (SPIT). OK, maybe not the best acronym, how about IT Operations as a Service (ITOaaS).

Anyway, the cloud still runs on physical machinery; maybe fewer and larger but boxes are not going away any time soon. I think that is one of the biggest hypes about cloud, at the end of the day it’s still computer systems, software and networks, information technology. There will always be a requirement for installing new hardware and someone still has to use the wonderful products created by those IT to Engineering career rotations. The question is who’s going to be operating and supporting those boxes. If you are using public XaaS, then ITOaaS is included in your XaaS. The IT career doesn’t go away; it just rotates to your XaaS provider. Perhaps you are a company that provides an XaaS platform, then you will still require those IT operations skills within your organization, the only question is this an Corporate IT or an ITOaaS career. The needs still exist, it’s just a question of rotation of the world, or not.

One thing that you can be sure of, everything does not work perfectly all the time (remember Murphy’s Law). The cloud is founded on the concept of fault tolerance and high availability but I have experienced the finger pointing that occurs when an application is not working as expected. Every supplier claimed 100% uptime, but that was not my user’s experience. Who do you think those users are going to call? I suppose it depends on who has what contract with what provider. Your XaaS providers will be looking individually at their components, but you are the one with the vested interest in getting things running again. You need someone to drive the incident response. Take a look at the ITIL processes; I think many of them will still be performed within your company by IT professionals.

No matter if it’s public, private or hybrid; single or multi-tenant, the cloud runs on computer systems, software and networks (information technology) which are still designed, developed, delivered and supported by people. There are still plenty of career choices in the broad field of IT. It’s the end of the world as we know it and I feel fine.

© Ellen Terwilliger 2012