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)

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

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)

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)

Get to the cloud (and save money)!

How many C-level executives have heard or uttered this phrase in the last week; for that matter in the last 24 hours? And how many of them really know what they are asking for?

The National Institute of Standards and Technology gives a good high level definition of the cloud. Is cloud computing really that new? As with most things, life is circular (what goes around comes around), so maybe the technology specifics are new but not the concept. Anyway, the definition states that the cloud will save money (hence the utterings in the c-suite). Cloud vendors (and what hardware or software supplier isn’t a cloud provider today?) continually ensure that the cloud will save you money; so it must be true, right? But will it really? Like all things, the answer is – it depends (don’t you hate that!).

There are great reasons for using Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). I think particularly in R&D situations where you have varying compute needs versus having dedicated hardware to meet your highest capacity compute requirements. Crunching big data is probably another area where the cloud could save money. In both scenarios I believe you need data retention policies that are enforced (probably true in or out of the cloud) to ensure your variable storage requirements and associated costs don’t just escalate. You have cost in set up and ensuring you continue to get what you pay for over time but you are relived of the day-to-day operational costs and pay for the benefits. I am sure you have other scenarios where you can save money using compute services in the cloud.

As indicated in an earlier blog, I love applications; I appreciate infrastructure (IaaS and PaaS) but it’s really just a vehicle to run applications (I am not biased or anything)! So I have a business operations application centric view when looking at the cloud. Software as a Service (SaaS) is the predominant cloud choice (or whatever aaS you want to call the on-demand flavor) for running your business. I am not convinced that the cloud is always a money saver in this situation.

The Upper Edge LLC blog has an interesting series about SaaS and On Demand contracts and whether there is really a lot of difference in your cost commitments, SaaS Matters: When “On Demand” Really Isn’t.  For you finance people in the crowd (or is that cloud) how do you feel about capital expense (CapEx) versus operational expense (OpEx)? I am such a conservative that predictable CapEx depreciation makes me feel good. Although from the Upper Edge point of view, maybe you get predictable OpEx using cloud SaaS options. Variable expense is something you should consider as you think about getting to the cloud and saving money.

Another cloud cost consideration from a business operations perspective is integration. Certainly in the early stages of your company, getting your business up and running is a great economical use of SaaS. And fit for function SaaS offerings which are best of breed in doing one thing really well are great choices too. But get too many independent SaaS offerings that need to work together and your cost savings may begin to erode or even disappear. There is not only the cost of integrating the applications but productivity must be considered also. If a single user has to go to multiple applications to complete their work and the configurations and integrations do not provide the necessary consistency, productivity could very well take a dive. The cost of supporting your business users in your unique cloud environment will also be affected by the consistency of integrations.

The cloud and saving money may often but not always be synonymous; it depends. So be cautious if cost savings are your only reason to “Get to the Cloud!”

© Ellen Terwilliger 2012

Why Transform: A picture is worth a thousand words

Here’s an example.

What does this represent to you?

• Why transform?

• Who will benefit?

For me this is an example of a manifest vision. The goal is to create a picture in your mind of why to transform and what success looks like. What do you see? For more on why you might want to have a manifest vision see the following: http://blog.manifestvisionsolutions.com/2012/03/07/the-value-of-vision-and-solution-description/

In the example you are part of a very successful startup company. To get going you made extensive use of cloud computing or Software as a Service (SaaS) solutions. It was great! But over time, your salesreps started to complain (salesreps never do that, do they?); they had to go too many places with different logins to get what they needed to know. It was taking way too long. And it didn’t seem consistent to them; what they had quoted didn’t match the win probability values on the opportunity, they could match their configurations and quotes but couldn’t find quotes they thought they had submitted as orders. And you noticed that your salesreps were spending way more time making sure their commissions were accurate instead of being out there selling. Does any of that seem familiar to you?

For this example, I might respond to the questions above like this:

Why transform?  To increase salesrep productivity and increase revenue; get the reps to spend more time selling!

Who will benefit?  Salesreps, sales operations, sales management, order management, shareholders

Success looks like a happy productive salesrep.

Obviously there’s more to it. People will have many perspectives, so depending on who you’re talking to you might get slightly different answers to the questions. But that’s OK; you want people to see what’s in it for them at the vision level.

Lots of people have commented on the importance of having a vision. Here are some observations I found interesting: 5 Reasons Why Vision Is Important http://www.youtube.com/watch?v=St4yaNJkdDQ

Vision has lots of applications; it isn’t limited just to the overall company reason for being. It is an effective tool in any cross functional transformation program where many people need to internalize a common purpose for change.

What do you think of the example? Will people will be able to see why to transform? Will they know what success looks like? I’ve seen a vision like the one in this example used on a program. It was understood by everyone; people were empowered and inherently knew what to do and why. No one was talking about how we couldn’t do something but about how we could and would get things done. It was a productive environment with rapid decision making done at the right level. And the results were spectacular, a global change on time and on budget which was rapidly adopted. Not bad for a little upfront investment!

Do you have a transformation program that could use a picture that is worth a thousand words, a manifest vision?

BTW: I do not endorse or oppose any of the companies whose logos do or do not appear in the example.  They are just the ones I thought of today.

 © Ellen Terwilliger 2012

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

Merger Styles and Business Integration Approaches

At one point in my career, I had more-or-less the same position for ten years; but during that time I was employed by five different companies.  And over those ten years, those five companies acquired dozens of other companies.  Each time I was acquired or we did the acquiring, I was responsible for ensuring that the two companies operated together seamlessly; from Marketing and Sales to Technical Support there was a need to be efficient and effective, as quickly as possible. No pressure!

There are many reasons that companies merge.  It is important to know what style of acquisition you are looking at before you decide how to approach integrating the organizations.

One of the first styles of acquisition I was exposed to was a straight market share grab.  The two companies were in the exact same business serving the same market and wanted to reduce the number of competitors.  In this case, integration is pretty straight forward; get on the acquiring companies processes and systems as quickly as possible.  There is nothing differentiating in this situation so move fast!

A technology acquisition is relatively straight forward also, especially if there is a relatively small installed base of customers.  I’ve participated in dozens of this style of merger; they are pretty commonplace in the technology sector.  In this situation the focus is on integrating R&D.  On the operational side, you typically just have to get the general ledger balances moved to the acquiring company’s books, link the networks and web sites and you’re in business.  Simple enough, right?

Acquiring a company which provides you a new product line might not be too complex as long as it’s a product similar to those you already have.  In this case, you will still be using the acquiring company’s processes and systems.  You have to do the technology acquisition work along with product set ups, some data conversion and new employee training; but it’s still pretty straight forward.  I have done a couple of these where the integration was done within the first 180 days post close.  I even did one where the merged company was operating on Day One!

From here it gets a little more interesting (Interesting is an IT term that means the cost and complexity just went up exponentially!).  There are three styles where significant diligence should be applied to determine the best integration approach.  I have been involved in acquisitions of each type.

The first is what I call a new business model.  This means we’re in the same business but there is a new go-to-market model involved.  In my example, an enterprise supplier (low volume-high dollar) acquired a distribution supplier (high volume-low dollar).  This is a nice blend for expanding market penetration.

The second style is new market segment.  A company with a consumer orientation is going to merge with an enterprise focused company.  This has the all considerations of the new business model along with different target markets.  This adds another layer of complexity.

The final style is the partial merger.  In this case you have to split some part of the business out of the parent company, this can be simple (like a single product line) or not.  There are lots of things to think about in this scenario!

There is no one approach that works best in the last three scenarios.  I have used neither (did a full new implementation for the merged company requirements), used the acquired company’s or used the acquiring company’s processes and systems.  In any of these last three styles the approach is that most common answer – “It depends!”

Have I left out any styles that you’ve had to handle?

Photo Credit: Scott Maxwell – Fotolia

© 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