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

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

Related articles

• What is business transformation? (petertarhanidis.wordpress.com)

Whatever can go wrong will go wrong – but you can be ready!

In the first week of my brand new career in IT (many, many moons ago) when I wiped out an entire disk drive while performing a backup (I followed the process exactly), through my first implementation (also many, many moons ago) when the physical back plane burned during go live and had to be replaced, to my most recent large scale implementation when the power failed in the command center in the middle of the production data conversion – I have been a victim of Murphy’s Law. On one program a colleague even gave me a framed lithograph of Murphy’s Law engraved on tablets (shown above) since it seemed we were dealing with some sort of disaster on a daily basis! Even today, I probably wouldn’t document any of these specific examples as a risk to my program (since the probability is low of reoccurrence in my lifetime); but I would certainly think about them!

Over the years, I have learned the value of proactively identifying the unique risks that could possibly befall my program (because Murphy never sleeps) so mitigation plans can be developed for those that could derail success. This is especially important for large scale transformational change programs where the opportunity for disaster to strike is more prevalent, just because there are more moving parts. By being prepared in advance, you can often prevent the issue from arising at all (An ounce of prevention is worth a pound of cure!) or at least have a plan in place and avoid panic.

The earlier you begin risk management and mitigation (notice I didn’t stop at just management, you will have to act too) the healthier your program will be and the more likely you are to be successful (remember according to McKinsey less than 40% of transformation programs succeed). In identifying risks, you need a few key pieces of data to start with: risk event/statement, impact statement, impact level of the risk and the probability that the event will occur.

So how do you get started with proactive risk management? I begin with identifying assumptions (Assumptions – Power for Programs). Conflicting and invalid assumptions are primary candidates to create risk although any assumption can lead to risk.

Here’s an example. In an 18 month program, my program manager assumed an eight hour workday in her master project plan (not too unusual, although we all know people often work more than an eight hour day, especially on major programs). Our system integration partner assumed a nine hour workday. Oops, conflicting assumptions! This created a couple of high impact/high probability risks as follows:

• Budget risk: $260,000 in unexpected cost (1 hour per day @ $25/hour for 40 developers for 12 months)

• Schedule risk: missed deadlines (10,400 hour discrepancy)

Since this was identified within the first few weeks of the program, we were able to prevent the risk from occurring by choosing a valid planning assumption and adjusting accordingly: no budget overrun and no missed deadlines (at least not for that reason).

There are different types of risks and many ways to approach risk mitigation. In the example above, we chose to eliminate the risk since it was straightforward to validate one assumption, invalidate the other and act accordingly. This isn’t always possible, so you can choose to minimize the impact of the risk (create a risk mitigation plan) or accept the risk (deal with the consequences should the event occur). A first step toward determining the mitigation approach is to score the risk impact and probability to identify the risks most likely to occur that will have a significant impact on your program. For those that rise to the top, you can take immediate action; eliminating or minimizing the impact. Through routine risk management you will be able to choose your approach for all the risks you identify leading to a greater chance of success for your program.

You can be ready for Murphy when he comes to visit your program!

© Ellen Terwilliger 2012

Assumptions – Power for Programs

The most powerful tool I use in leading transformational change programs is assumption management. Over the years, I have contracted with hundreds of project managers and most of the leading system integrators; none of them actively used assumptions. Maybe you are wondering what I am even talking about.

One place assumption management has been discussed is in regards to software development and defects by The Software Engineering Institute (SEI) at Carnegie Mellon. The article states that most of the defects discovered in existing systems were probably caused by invalid or changed assumptions. I believe major programs fail, or experience huge cost overruns , for the same reason. Many programs don’t even consider what assumptions are out there. Project management methodologies refer to assumptions and there are even a few companies that have based an offering on assumptions and risk management, but very few programs actively use assumption management as a communication and alignment tool throughout the project lifecycle.

First of all, what are assumptions? Merriam Webster says an assumption is a fact or statement (as a proposition, axiom, postulate, or notion) taken for granted. No matter how many people are involved at whatever stage of your program, everyone is making assumptions and taking for granted that something is in fact true. And I can guarantee you – assumptions are being made that are mutually exclusive; they conflict with each other. Why does that happen? Diversity is a key aspect of transformation teams, individuals are selected to provide broad perspectives and different points of view, so it is natural to see things differently and therefore assume different things. Assumptions are not right or wrong; they are just valid or invalid within the context and timeframe of your specific program. The power in that is that people don’t need to fear assumptions.

What do you do about assumptions, especially those that conflict? The first thing is to identify and document assumptions. If you don’t know what they are, at each stage of your program, you certainly can’t do anything about them. Depending on the stage and size of the program there are different ways to collect assumptions; interviews and questionnaires being the most common methods. I then use a matrix to categorize and de-duplicate the assumptions. The matrix provides the framework for the assumption validation meeting; where the cross functional team rapidly reviews every assumption for validity and risk potential (more on that in another blog) with special focus on conflicting assumptions. If conflicts cannot rapidly be resolved then they are set aside for deeper review and validation. You’ll find that a lot of other assumptions come out during the validation meeting allowing for an even deeper understanding of the program. This type of meeting is one of the most effective communication and alignment tools I’ve used; people are open, engaged and animated; they come away with a real sense of ownership because they are involved. All this increases the probability of success for your program.

Remember that assumptions are vulnerable; they can change or become invalid over time. That is why periodic review and refresh is essential for longer duration programs. I recommend stage gates and/or testing events as opportune times to collect, review and revalidate assumptions or incorporate assumptions as part of risk management. After all, an ounce of prevention is worth a pound of cure.

Can you see the power of using assumption management in your programs?

 © Ellen Terwilliger 2012

Related articles

• Project Wisdom: Step 1 (tuitionpaidlessonlearned.wordpress.com)

Why the Manifest Vision Solutions Blog?

  

My name is Ellen Terwilliger.  Over the last 20+ years I have been responsible for global business applications for a number of Fortune 500 companies.  I love apps!  But more, I love the value that is received when people, process and technology work together end-to-end and make a difference.

My husband, who is in the home health care field and knows absolutely nothing about business, asked me over the years to describe what I do and why I like it.  This is the best way I’ve learned to explain it:

What I do is like putting together jigsaw puzzles.  And not those cute 100 piece puppy dog puzzles either.  In these jigsaw puzzles you don’t know how many pieces there are, the pieces are all cut in similar ways, the picture is the same on the front and the back, the borders are not straight but misshapen and there is often more than one way to complete the puzzle.  Sometimes the puzzles are even 3D!  Putting the puzzle together correctly is like getting a business to run effectively and efficiently.  In addition, I don’t actually touch the puzzle pieces; I influence others to describe and understand them, move them around and ultimately make them fit.  Of course over time I have seen a lot of puzzles and a lot of pieces; but it’s important every time we do a puzzle that everyone working on the puzzle has the same view of the pieces, and the puzzle.  Doing jigsaw puzzles is complex, it’s never works the same way twice and something unexpected always happens.  I thrive on the variety!  Like putting the puzzle together, making business run well is challenging but when it all comes together, it looks cool, is incredibly satisfying and a lot of fun!  I love what I do!

This blog is intended to share experiences and lessons I’ve learned while completing those jigsaw puzzles.  I hope it will help business leaders and anyone involved in attempting to make large-scale change to avoid some pitfalls or better yet, learn something that will make a difference and help you be successful.

Do you like jigsaw puzzles?

© Ellen Terwilliger 2012