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

What is a vanilla implementation?

It’s doesn’t matter what type of software you’re implementing or for what purpose, Einstein’s quote is the guide to success; finding the balance point of simple is the key to a vanilla implementation.

Software is created to perform a function, typically a function that many people do on a regular basis. The product designers spend lots of time understanding the commonalties of the function in order to create a product that follows Pareto’s Principle or the 80-20 Rule. The 80% is the same for everyone; it’s standard/vanilla and is going to work just fine for your purposes. It’s how you handle the 20% that determines how vanilla your implementation will be.

From the software application perspective, here are three rules of keeping things vanilla.

Rule #1: Extend – never replace. If the application does it, use it. If shipping capabilities exist within the software then use it. Don’t reinvent the wheel; extend from the hub to add the uniqueness you require. That’s kind of your own 80-20 rule; you can use 80% of the functionality of the code that’s there and just add on your own 20%. The total cost of ownership for the 20% is a lot less expensive than 100% of your own development and support. Plus, you’ve already paid for the capability (and continue to pay support) so you certainly don’t want to pay twice! The question to ask in regard to Rule #1: Why doesn’t the standard capability work for my company? 99 times out of 100, there is just one specific situation where you need something a little bit different.

Rule #2: Extend – never change. Never modify standard application code or data structures. I have always told my teams: “Tell me the 25 other ways you’ve considered before saying you have to modify standard application code”. Almost every software manufacturer provides a method to extend the functional capabilities of their package. You may need to do some unique calculation or capture some additional data. Use the hooks provided to interrupt the flow of the process, do what you need to do, then come right back in where you left off in the application flow. This is what allows you to continue to upgrade as new versions of the software are released. In my career (many, many moons), there have only been two times when a standard code change was required. And believe me – everyone who ever worked with that section of the application knew about it and how to deal with it, talk about documentation!

Rule #3: Data drives flexibility and scalability. Every software application is configured to distinguish Company A from Company B. The data values that drive the function you are automating is what makes your company yours and allows you to extend the functionality to meet the unique needs of your organization. For example, imagine you are a company that provides financing directly to some of your best customers. Only 1% of the time is this option selected. By creating a unique value, “Financed” associated to the quote and order, you can create a hook when that value appears to capture additional data and determine differentiated pricing, for instance. You don’t change the way quotes and orders are entered or processed, you just add to it and perhaps do some overrides. If you decide later you’re not going to do that anymore or do it in a different way, then inactivate the “Financed” value or add a new value to drive behavior differently. You’ve handled the 1% and left the 99% as business as usual: vanilla.

If you follow these three rules you use what is there and have not modified the code or data structures as provided by the software manufacturer; you have a vanilla implementation. You added your 20% of uniqueness in a way that maintains the integrity of the supplied software. The ease of doing this varies based on the tools associated with the specific software application; some suppliers force the behavior, with others you have to be more diligent.

Of course, there is a bit more to it than that. How you implement in a vanilla fashion is one thing, the bigger measure of the “vanilla-ness” of your implementation is what you choose to put into the 20%. As I described in the rules, this is a question of uniqueness and value; unless there is something to differentiate you from your competitors, why spend the money? How do you know what is truly unique and differentiating about your company; where is the balance point for simple as described by Einstein? Software can do anything you can imagine but you probably can’t afford for it to do everything.  I always like to say “Just because you can, doesn’t mean you should”.

Start by understanding the best practices for the function and in your industry (the 80%) and then state specifically (in writing) what is really special about your company in these areas (the 20%). Be aware if anyone says, “We’ve always done this, we have to have it!” For every unique factor, describe how this differentiates you from your competitors and what benefits are derived. Don’t forget about reporting; you will look at your data differently from others and you may need to feed your business intelligence applications for a more holistic look. Based on this, have a rating and ranking exercise performed by the program sponsors and executive leadership. This sets you up to find the balance point of simple for your implementation.

Vanilla now becomes a budget decision. Figure costs for environments, configuration, testing and change management, that’s your baseline. Determine rough estimates for the ranked list (only go as far as you think necessary). From there you can determine the cut line based on the budget for the program (or adjust your budget accordingly). Voila, vanilla!

There are three simple rules to follow for a vanilla implementation: never replace, never change and drive with data. The harder part is the choice of where to differentiate your implementation and your company. Vanilla is permission to play; the balance of simple is winning.

© Ellen Terwilliger 2012

Related articles

• Did a Fortune 1000 CIO really say “No” to custom software? (ectobox.com)

Software: Limited only by Imagination

I have been challenged with a lot of different and complex puzzles over the course of my career. But I must say that I have often found software to be the most challenging of them all. This is because with software there is nothing physical to tie you down (yes, it has to run on something but these days that’s not too restrictive). Your only limitations are the imaginations of product development and sales people. In my experience that is no limit at all!

Just look at cloud computing. There’s lots of hardware sitting out there waiting to be called upon at a moments notice. But it’s the software that enables you to add capacity on demand. It’s the software that makes you able to share a platform development environment. And of course “software” as a service started the whole cloud computing revolution.

And just look at the number of applications available today. It boggles my mind when I go to the app store and browse. There are lots of very creative people out there building software to do things I would never have dreamed possible.

From a business perspective, what makes software so challenging? If the software is put out in cyberspace for free and it’s “buyer beware” so you don’t provide any support, then software is pretty simple. But the minute you decide you’d like to make some money off this good stuff you’ve developed, that’s when the complexity begins.

There are lots of things to think about once you decide to sell your software (the reality in the quote above). Beginning with deciding what feature sets you are going to offer, through figuring out your pricing and licensing models (more on this in future blogs), to considering your fulfillment methods while protecting your intellectual property and ultimately setting up technical support and renewal methods (after all you want to keep that revenue coming in, right?) there are a large number of operational business processes involved in keeping it all running. For the finance people in the crowd, there is revenue recognition and tax to worry about too. In addition, if you’re offering your software as a service, then there’s the whole platform and 24X7 global operating considerations that can have a significant impact on your brand if not done right.  Here’s another perspective on the difficulty of the XaaS business, Even the Tech-Savviest Struggle with Cloud Based Business Models.

Remember those development and sales people? While you’re thinking about all the stuff in the last paragraph, they are busy changing the license models and coming up with new ways that they could bundle things together to make it easier to buy. And the list goes on. I am so impressed by the people who create at such a rapid pace. Imagination is an awesome thing!

For those of us who are trying to keep an operational model functioning at the speed of software innovation, it makes for a pretty complex and ever changing jigsaw puzzle. It is never boring and that’s what I like most about it!

Do these sound familiar to you? What other challenges have you faced in running a software business?

Graphic credit: The world of imagination is boundless (via Behance)

© Ellen Terwilliger 2012

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