Choosing a Functional Area for Transformation (???)

First comment – don’t. The functional areas you ignore will negate any transformation in the area(s) you chose. ALWAYS perform transformation at the enterprise level if at all possible.

Second comment – make it possible (to perform a transformation at the enterprise level). ALL your arguments will be valid. Although all excuses sound sensible at first, they are dangerous rationalizations. Don’t listen…

That said, it is (somewhat) common to implement a sequential functional ‘sleeve’ approach. Once you complete all functional ‘sleeves’, you’ll have completed the entire enterprise portfolio. This is doable. However, the extended time required increases the risk of completely the entire enterprise sleeve-by-sleeve. Remember the old adage, “time kills deals” — rings true for transformation projects as well.

Pros of a Sequential Functional ‘Sleeve’ Approach

• Built-in go / no go decisions points at end of each sleeve’s assessment
• Functional-specific recommendations delivered quicker
• Allows focus on known ‘problem areas’
  • Look first at high value, low risk, quick return items
• Savings from initial sleeve(s) recommendations, when implemented, could be used to fund assessment of later sleeves
• Can factor in risk / complexity to ensure success and high return early to best position higher risk, more complex efforts

Cons of a Sequential Functional ‘Sleeve’ Approach

• Takes longer, total cost is greater to asses entire portfolio using a sleeve-by-sleeve approach
• Multiple modernization roadmaps and business benefit models will need to be ‘rationalized’ into one, at the completion of the final sleeve (e.g. completed enterprise)
• All redundant functionality may not be discovered within a narrow scope of individual sleeves
• Possible re-work on earlier recommendations as additional sleeve assessments are competed
• Implementation of recommendations while completing additional sleeve assessments could add complexity to the level of effort required
• A narrow sleeve assessment would result in increased assumptions / less actual recommendations
• Retirement / replacement recommendations will need to be vetted with additional (out of scope) users of each application

Pros of Enterprise-wide Approach

• Maximized value by delivering enterprise-wide recommendations
  • Recommendations will minimize conflicts for limited FTEs and funding
• Minimized time and investment in actual assessment
• Timing considerations, critical dependencies, and design complexities can be determined across the enterprise for all recommendations
• Composite view of data warehouse, business intelligence, data sources, etc. provides increased clarity
• Enterprise-wide business case makes funding decisions more strategic
• Increased business scalability and agility

Cons of Enterprise-wide Approach

• Very few recommendations are implemented until after the completion of the assessment. There are exceptions to this…
• The complete solution will be delivered in a multi-step fashion
• The enterprise-wide roadmap solution would require increased time to reach a decision / funding approval; and volatility of work and demand for client resources
• Organizational risks could be increased as multiple recommendations are implemented across broad functional areas
  • Business resource availability
  • End user change impact
  • Other project commitments

What Both Approaches Have in Common

• Determine what applications are in use supporting the business
• Which applications score best and worst for function and technical quality
• What applications are based on ‘at risk’ technology
• What applications cost the most to maintain?
• Determine what applications should be retired, consolidated or extended
• (Assuming implementation of the findings) Reduce portfolio total cost of ownership (TCO) and / or enable spend redirection from sustaining work to high value-add initiatives
• Alignment between applications and business objectives
• Increase the performance, efficiency, and usability of a portfolio
• Similar assets will be delivered

In addition, an enterprise-wide approach can result in additional value such as analysis of:

• IT organization model
• Current projects
• Portfolio management
• Governance practices

A functional-sleeve approach will not allow an across-the-organization view of these areas. It is extremely difficult (e.g. near impossible) to stitch together a message sleeve-by-sleeve across these important areas.

Quiet convictions (e.g. enterprise view) often earn long-term respect.

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Defining Application Tiers

“The secret power of lawlessness is already at work!” — means the any future work based on tradition (e.g. the past) is already going on. Secret means something no one has discovered, but something that will be revealed in any transformation effort. Lawlessness is the hidden, subtle, underlying force from which “we’ve always done it this way…” springs.

Rationalizing the need makes it easier to commit, but rationalization does not convince executives or cancel legacy practices that brought you to the point at which you find yourself today.

Why define tiers?

So…you’ve discovered and documented your portfolio of applications. Congratulations! Do you know how many companies don’t have their portfolio documented? Most of them…

Are you surprised how big your documented inventory is? I’ll bet you didn’t think you had that many applications? The list invariably includes business applications, IT tools, interfacing applications, middleware, utilities, and desk-top productively apps. You name it, you’ve got it in your inventory. Again, CONGRATULATIONS!

So… now that you have your inventory, you are ready to manage one of your firms largest assets more effectively, therefore reducing costs, right? Then why can’t you? Ask yourself, what do business applications and IT tools have in common? The answer is ‘nothing’.

Don’t get me wrong, a complete inventory is THE essential first step. The second step is just as important — YOU MUST DEVELOP A TIERING MODEL in order to effective focus your attention on what needs your attention.

Why?

You could retire 100% of your IT tools and not save enough money to pay for the inventorying effort. On the other hand, understanding what the business truly needs in the way of functionality, reporting, and forecasting is worth its weight in gold.

The Secret of Developing a Tiering Model

There is no secret. Rather, you just do it…

Maybe one secret: Compromise can be defined as a blending of the qualities of two different things or a concession of principles. Cooperate with people (e.g. business people if you’re in IT, IT people if you are in operations) as much as you can, but avoid any alliance, partnership, or participate that could lead to continuation of the current state, and more importantly, a water-downed less-than effective future state strategy.

Your tiering model does NOT delete anything from the composite inventory. It DOES tier less important things out of your way. You want your transformation focus to be on business applications – those enterprise and regional apps that are generating revenue, profit, and keeping your customers onboard.

An example might be:

Tier 1: Enterprise, business unit or regional level applications critical to the firm’s business processes

Tier 2: Plant specific, non-industry specific business applications

Tier 3: [Utility Example] Specialized generation, transmission, or distribution applications or tool sets

These 3 tiers would be your focus for any rationalization, modernization, or transformation effort. Experience shows that the majority of cost savings can be realized by transformation of business applications. In most organizations, these three tiers account for about 40% of the total portfolio.

Tier 4: Everything else

Not so fast… Additional cost savings may be identified in other tiers, so a little effort in this area may be of additional value. Something like:

Tier 4: Desktop office productivity applications

Tier 5: IT and system applications for backup, security, help desk, testing

Tier 6: Development applications & tools

Tier 7: Data subscriptions, services and unknown applications

You may also want to consider additional criteria such as:

• Previously identified rationalization candidates
• High support-cost applications
• Focus application-areas for business standardization or improvement
• Linkage to in-flight projects
• Identify “top business processes”, and look at the world of actual applications and desired standards for these processes

Remember, ask yourself, what is the value in this particular tier’s definition? For every tier defined. Point is, each tier must be defined BEFORE linking each application to its appropriate tier. The tier number simply becomes another attribute that helps you define and management your portfolio.

If you are a reader of my blogs, you’ll remember that ‘tiering’ is directly linked to ‘Defining an Application’ – check it out @ https://appstrans.wordpress.com/2015/07/08/defining-an-application/

Again, with larger portfolios a tiering model is developed to provide focus on the upper tiers that will provide the largest payback in any transformation effort. A completed example may look something like this:

What’s Next After Tiering?

Simply put, begin the analysis of your current state inventory. But Frank wait, Frank, Frank, do I perform an analysis across the enterprise or functional area-by-functional area?

You are finally asking the right questions. Until next time…

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Defining an Application

How is behavior altered? In his book “The Social Animal”, David Brooks notes that some experts have said people just need to be taught the long-term risks of bad behavior. Unfortunately, in the world of applications, this hasn’t been enough to transform behavior.

The understanding of the current state portfolio is much more important than any transformational strategy. Why? How can you begin to determine where you need to be (future state) if you don’t understand where you are (current state)? In addition, a sound knowledge of the complexity and gaps in support of the business will go a long way in determining what the strategy should be and where it should take you.

This is an extremely difficult task: “Telling people, who truly believe (and in many cases helped build it) in the portfolio and what it provides, that it will literally destroy their company if they don’t (immediately) begin transforming it?” Difficult indeed…

I’m NOT talking about the infrastructure (e.g. the ‘machines’, or whether they reside in the cloud or not. Nor the data, nor the connectivity, etc.). I’m talking about the applications themselves – those systems and pieces of software that your employees use to access knowledge and information that keeps your company alive and competitive.

Why is defining what an “application is” so difficult?

Today’s heterogeneous application environments defy simple definition. Applications tend to lack any truly useful or standard unit of measure. Today’s applications are a mix of massive, client / server, packaged, service-oriented architecture (SOA) services / web applications, etc. – no one definition seems to apply. For example, how do stored procedures and / or reusable components change a definition? Will SOA services erode the definition entirely by replacing silos with loosely coupled shared services? How should open-source be counted — as custom code, a partial-packaged application, or a service?

Firms that have spent excessive time debating the term “application” have likely lost track of their context or never properly defined it to begin with. Context – arguably an ugly word. Context depends on what you are doing — your objectives, goals, and perspectives.

Some contexts require a high degree of technical precision. Operations and change management that run / migrate applications to / from production require precise inventories of components making up each application. On the other hand, a developer may define an application by its source code, shared components, data, and /or integration.

Other contexts define applications by the technology base. Enterprise architects (EAs) may assemble a view of applications based on the technology used — database management systems, OS, and programming languages, for example. These usage-based views enable EAs to monitor the cumulative technology in use, ensure adherence to technical policies and standards, and making recommendations to retire obsolescence.

Still other contexts blur or ignore application boundaries. IT and business leaders may group applications together to approximate the resources that the business consume. Business process SMEs may ignore application boundaries entirely to focus on how future-state processes should flow regardless of the current-state applications. EAs may take a similarly intellectual view as they develop capability maps and future-state diagrams.

Where do I start?

Good question. Before we get into the nitty-gritty of defining an application, the basics apply to this endeavor:

• Calculate the investment
• Set priorities
• Prepare
• Determine a course of action and move ahead boldly

Just what is an application?

To start, you don’t need tedious planning sessions, you need one plan that will bring quick action. You simply get the definition right to create transparency and enable transformation. Start with a ‘working’ definition…

This working definition is used to narrow the focus – this first-scrub should significantly reduce the list of application ‘candidates’.

The first step then, is to apply a general application definition to these ‘candidates’. Ask, does it:

• Accomplish a specific task(s)?
• Aid the firm in performing business?
• Create, edit and/or store data?
• Require support and maintenance?
• Can upgrades be deployed separately?

If the answer is “yes” to all of the above questions, the definition moves to the second level of analysis. Step two refines the definition:

• Does it communicate with other systems?
• Does it have licensing, maintenance and / or support costs?
• Is it a system of record?
• Does it create, edit and / or store ‘enterprise’ data?
• Does it require manual process(es) to engage / interact with?

If the answer is “yes” to any of the above questions, the definition moves to level 3 of the analysis. The third, and final, step involves identifying application ‘buckets’:

• Does it ONLY support out-of-scope functional (OOS) areas? Yes, you determine what OOS is / isn’t
• Is it a non-business application? (IT & system apps for backup, security, help desk, testing, development apps & tools, data subscriptions, services, and unknown apps)
• Has it already been retired or replaced?
• Etc.

Based on your unique context, only the in-scope applications are inventoried and analyzed further. Transformation is not produced by neglect, denial, withdrawal, or bitterness. It only comes from extremely hard work tackling difficult problems.

But wait, how do I identify which of my applications are business applications? It’s called ‘tiering’. Until next time…

See you in the future…

Frank Wood

Frankwood944@yahoo.com

Managing an Every-Changing Master Inventory Requires Meticulous Hands-on Governance

Don’t have an APM team? Get one!

Combining two lists into one master list can be done relatively easily. Combining several dozen lists into one master is a significant challenge for anyone:

• Removing duplicates becomes extremely challenging. A (must) by-product of this is standardization of naming conventions (TLAs [three letter acronyms], common names, nick-names, official names, names of vendors in lieu of software names, etc.)
• Redundancy in TLAs becomes an issue – oh, yes it does…
• Tracking all the individual tidbits of information from each source-list that needs to be rolled into the master inventory becomes mandatory and increasingly difficult
• Identifying only the new applications becomes more challenging as the master list absorbs more and more source lists
  • Performing this manually can become a major risk for any project’s time line and / or deliverables
  • A tool is required to insure that no information is lost or over looked from the source lists and insuring only new applications are added to the master list

Example De-duping Tool

How to use a dupe-identification tool like the one shown above:

1. Clear the contents of columns 1 and 2 (below ‘black’ header row) as applicable
2. Update the contents of columns 1 – 2 with lists of applications that have been identified to date (Note: Change column header where necessary)
3. Enter new Application list in “new list” column as shown (below ‘black’ header row)
4. Click on the “Identify New Applications” button (note: requires VB code not shown here)

• “Analysis” Column will display the analysis
• “Potential New Items” Column will display potential new applications – final analysis of these potentials will need to be done manually by APM team

When done, move the entire list from “new list” column into the “Processed Lists” tab. This will help you limit duplicate analysis of new items as you move through additional list yet to be de-duped.

Processed list is then moved to ‘processed list’ tab.

Then the tool is ready to analyze the next source list, repeating the process.

The lists considered MUST include shadow IT (Underground apps, departmental IT, etc.) applications. The ranks of business people (e.g. business end-user developers) who are capable of developing applications are swelling due to:

• Technology-savvy workers entering the workforce
• The proliferation of easy-to-use development tools
• Burgeoning demand for applications

These business people don’t want developers’ jobs; they just want to get things done. Their enthusiasm and lack of professional application developer backgrounds can lead to poorly designed, insecure, and un-scalable applications that application development professionals ultimately inherit.

Business users gone wild…

End-user developers can easily get in over their heads. Armed with BPM, business rules, Excel, SharePoint, Drupal (an open source content management platform), enterprise mashups (e.g. integrated heterogeneous digital data / applications from multiple sources for business purpose(s)), and other tools, end-user developers have virtually no limits. The result can be applications that proliferate out of control.

Most application rationalization efforts ignore end-user-developed applications and that is a BIG mistake. Just because they aren’t developed under IT’s radar doesn’t mean they shouldn’t be included in a firm’s MASTER inventory. Understanding the ‘why’ behind these underground applications, can go a long way in identifying potential gaps in the IT offering.

These applications can replicate faster than enterprise architectures can develop standards for controlling them, especially when developers can email or deploy them on a web-based platform. End-user development is often not subject to the same stringent testing regime that is employed during standard IT software development processes. Hidden bugs can cost millions.

Do You Shut Down Development All Together?

No. Although simple applications can become beasts, any end-user developer armed with an idea, ambition, or need can build significant applications – that, over time, can become strategic. The challenge becomes when businesspeople embed numerous home-grown applications in critical business processes that result in a convoluted process that makes a business less agile. WHY? Business developers often work alone. A business process that becomes dependent on a businessperson-developed-application might become dependent on the person who developed it. When they leave the firm, what happens to the application?

With or Without IT, Business Developers Are Here to Stay

The ranks of businesspeople who are willing and able to develop applications are increasing due to the proliferation of easy-to-use development tools, demand for functionality that outpaces IT’s ability to keep up, and the growth of cloud computing. They don’t want to become developers; they just want to get things done within their OWN timeline. With their enthusiasm comes poorly designed, insecure, and stand-alone (e.g. no interfacing) applications that development professionals in IT ultimately inherit.

Instead of ignoring or trying to shut down business developers, the organization should provide EA guidelines and standards – to insure success and safety for the business. Business ALWAYS preserve the right for business-needs, desires, and wants. Business CANNOT tell IT what is the best solution – that is the business of IT! However, you must identify a way to provide a strategy that illustrates to business executives you are trying to get out of their way while preserving some sanity in their future-state solutioning.

Next up — Why is defining an application so bloody difficult?

See you in the future…

Frank Wood

A Business Based Approach to Application Portfolio Decision Making

It is important to take a self-inventory in order to identify strengths and weaknesses. Whenever in doubt, ask, “Can I do that without the business? Can I influence others for good, rather than being influenced by them?” In areas of strength, you should guard against being corrupted by the enterprise; rather you should be persuasive in your transformation ‘story’. In areas of weakness such as an immature transformational vision that has not yet been developed, you need to be cautious.

Business Context

1. What is my current state application usage, technical constraints, and operational speed bumps?
2. What is the current state of our business? How does the portfolio currently support the business? What is the future state of our business? How does the portfolio need to change to continue to support the business in this future?
3. What applications do we have, who owns them and what business capabilities do they support?

Many times, transformational architects base their planning on opinion, personal dislikes, or cultural bias rather than a sound strategy. Hoping is not an alternative to preparation and your personal belief is not a substitute for hard work. You must leverage all the talent and resources available within the enterprise.

MUST HAVE: Application Risk / Financials

1. How complex is your application portfolio today?
2. How complete is your application data (e.g. basic knowledge of each application)?
3. How do application costs and risks align to business capabilities?
4. What are the existing skill sets and FTEs for each application?
5. How successful have your past transformational efforts been?
6. How does the cost of an application and the value it provides compare? Does the business agree with this comparison?
7. How do you estimate an operational TCO for each application when that data isn’t available?

Many people think that prosperity and success come from having power, influential personal contacts, and a relentless desire to get ahead. But the strategy for gaining affluence goes against such criteria. You must be:

1. Strong and courageous because the task ahead will not be easy
2. Obey corporate governance – transformation does NOT play outside of this realm
3. Constantly read and study transformational thought, vision, and best practices

MUST HAVE VISION: Consolidation Opportunities

1. Is there opportunities to consolidate applications across regions and business units?
2. What are the best candidates for rationalization? Better yet, what is the criteria you use to answer this question?
3. What applications are you planning to retire? Why haven’t they been retired yet? Somebody in the decision tree ultimately will ask THE question, “What is this application retirement going to save me?” Or, “Where is the data going to end up?” If you can’t answer both of these, don’t even attempt retirements / replacements…

You may ask, why all the complicated preparations for transformation?

• Success will depend on a transformational vision NOT culture and expertise
• Transformational leadership will accentuated the enterprise ‘stuck in the mud’ mentality
• Faith in your willingness to follow through completely is paramount

Challenges (These WILL Happen)

• Inventory
  • Not complete and up to date across the enterprise
  • Not kept in a central location and easily accessible by business and IT decision makers
  • Most will think ‘inventorying’ is a waste of time, saying, “Let’s get on with the real transformation!”
• Consistently updating the inventory is the only way to continue making good investment decisions
  • How do you decide where new technologies such as cloud and mobile change the importance of various applications and delivery platforms if you don’t keep this information current?
  • Inventorying is not a one-time effort, rather a continuous tracking, documentation, and analysis of one of your firm’s largest assets
• Prevent ‘”Shelfware
  • Gather organizational support needed to implement the transformational change(s)
  • Delivering real business benefit (reducing costs – remember operational TCO, reducing risk, increasing agility)
• Step-by-step
  • First, commit to measuring the performance and business value of each application
  • Identify both business owners and IT owners for each and every application
  • Focus on answering the most critical challenges facing the business

When you experience a setback (and you will…):

• Man-up and ID what went wrong and why?
• Refocus, deal with the issue, and move on – this cycle will strengthen the transformation effort, not weaken it
• Lessons learned from failures should make you better able to handle the same situation the second time around

The persuasive power is in the transformation ‘story’ not the transformational leader (e.g. storyteller). The organization (e.g. business) won’t be against those who carefully prepare, but against those who try to impress others only with their own knowledge. Following these important principles will insure success:

• Find common ground with the business
• Avoid a (technical) know-it-all attitude
• Make the business feel accepted
• Be sensitive to the business’ needs and concerns
• Look for opportunities to make the business more successful

See you in the future…

Frank Wood

 

 

Application Portfolios – The Paradox

“I almost like it, even though it sort of irritates me. Maybe I like it because it irritates me. But that’s my problem“.

OK, so you have a massive application portfolio with technology that is significantly outdated. In addition, the application landscape has grown without currency maintenance. In other words, many of your servers are outdated to the extent you can’t upgrade your core applications, and many of your servers cannot be upgraded because the upgrades won’t support the most current versions of software. And let’s not forget the last acquired business unit – they are still running on all their own systems.

In a September 2012 survey, Gartner found that “78% of application portfolios will change over the next 2 years.” That was 31 months ago. Did yours? If yes. Is it going to change again by 2017? If no, how is your legacy portfolio going to support your business differentiation in 2016-17 and beyond?

Everything has a Price

“Everything has a price” seems to be true in our world of expanding markets, revenue, growth, M&A, and divestitures. No amount of money however, can buy optimization.

Most firms have already adjusted to their competitors’ differentiators, global market forces, and every-growing customer demands. The only way to leverage the power within an application portfolio is to discover, document, analyze, and then, develop future strategies from your findings. Those strategies must transform your current state through portfolio standardization; process refinement through governance; managing the portfolio via established metrics / measurements; and proactively optimized assets. In short, transform the portfolio so as to optimize the knowledge and enhance the business support derived from it.

First Things First

1. Begin by following your instinct for the obvious need to transform – starting with where the concerns are
2. Define where you are today (the good, bad, and ugly) – then you can demonstration how transformation applies to those concerns
3. Explain the forethought of your future state – but don’t forget / neglect the current state, it defines the scope of your transformation

Suddenly Transported to a Future State?

No. A bold vision will no doubt stir up controversy. Knowing this, you can prepare for it.

1. Don’t lose your fierce intensity, rather channel it
2. Ensure your intentions and efforts are sincere
3. You must be an apostle of your transformational beliefs
4. Realize little has been accomplished to date, you are going to be different – you are on a missionary journey

You will never know all you can accomplish until you allow transformation to identify all that you have need of. Hearing is absorbing and accepting information. Learning is understanding its meaning and implications. Following is putting into action all you have learned and understood. All three parts are essential in a successful transformation.

An “IT transformation” is not just a tech initiative within IT, it is a business strategy adopted throughout a company.

1. Recognize what is currently taking place
2. Renounce this state as unworthy of expansion / extension
3. Ask for support, funding, and insist on executive backing
4. Restructure your priorities, therefore the motivation for each
5. Examine progress daily to be sure the business units are spending the time and making the commitment to quantify transformation benefits

Transformation Cannot be Ignored

How would you feel if someone took a picture of you, framed it, stared at it a lot, showed it to others, but completely ignored the real you? Transformation cannot be treated that way either. First it is a movement, a large activity, a migration. At some point it becomes much more. It becomes the ‘new you’ – the transformed organization that is quicker to respond, more agile, more cost effective, AND won’t have to stop and perform another application assessment because you are pro-actively management the portfolio.

Hardest Challenges

1. We’ve always done it this way. Sure it’s tough sometimes but we’ve managed so far…
2. Resentment for change in leadership – transformation may require new leadership with new vision and priorities
3. Lack of vision can spread like an virus
4. The rigors and challenges of transformation
5. Some may want to transform ‘only a little’, rather than the entire journey – most CIOs will want to knockoff projects incrementally, even if they have a vision for how they’ll work together. That approach will deliver benefits but for an IT group to change the company’s edge over competitors – “be the benchmark”  – means taking on all weak spots at once

Belief in Monotheism

For a company that has wandered 40 years in a parched desert of hair-ball architecture, a future state flowing with knowledge and agility probably sounds like paradise. Don’t wait around for a miracle. Sow your seeds of transformation on the best ground you can find the best way you can, and leave the convincing to your success of reducing cost, complexity, and increasing agility and a vision to your future.

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

Transformation Deliverables That Deliver Business Value

Does this sound familiar?

How many of your colleagues call ‘their buddy’ in IT whenever they need something? Who’s the business owner of the application(s) you use every day? Do you own an app that will perform (fill in the blank)? If no, then it’s a manual activity, correct?

Decreased OpEx: Why do I have to key in this data manually when it’s available from (fill in the blank)? Why are there so many timesheets? Why are my IT chargebacks so high?

Improved business case development: Who struggles with estimating benefits in a business case? Does any application really operate for free?

Lower support costs: How many people work on reporting each month? What % of my staff’s time is spent on the ERP system? Can it be reduced? Why is my app not available?

Reduced complexity, redundancy, cost: How many apps do you use that are not supported by IT? What app houses the ‘single point of truth’? Is part of your job the ‘manual interface’ between applications?

Improved business support: Why can’t we get rid of this old dying system? Why can’t we upgrade this one? Why can’t we expand the functionality of these two?

Improved investment decisions: Why are my requests never funded? In the last year, we’ve successfully completed every request by the business but strategically, we haven’t moved the needle. Why?

Improved business support strategy: What’s the plan? Where are we headed?

Greater efficiencies: Why’d we invest in that? Why do most projects run over budget? We spend the budget but never realize the benefits. Why?

Increased decision making ability: Who should be involved in this decision? We’ve got all this data, now what do we do with it? How do we reduce costs / risk exposure?

Is there anyone that delivers answers to ALL these questions during a typical assessment?

Yes. Maybe, just maybe, I’ll see you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

“Houston, We Have a Problem.” We Aren’t Responding Quickly Enough to Business Needs!

Class reunions, photo albums, familiar songs, and old applications – like longtime friends that awaken our memories and stir our emotions. The past is a kaleidoscope of promises, failures, victories, and embarrassments. Sometimes we want to forget memories that are too painful. As the years pass, however, remembrances of unpleasant events usually fade into our subconscious. But there is a time to remember: Mistakes should not be repeated; commitments made must be fulfilled and the memory of special events can encourage us and move us to action.

The Israelites spent 40 years on a journey that should have lasted 11 days. How long has your company been building the hair-ball you call the ‘current state’ application architecture?

The case for a strategy

Lacking a strategy, past generation(s) have been coding / building / buying software for up to 40 years and have perished into the wasteland of:

• “Put-out-a-fire” architecture,
• Point fixes that don’t fix problems,
• Bypassing middleware because it’s “cheaper”,
• Departmental IT

Are you your firms’ Moses?

After the organization choses to follow any transformation, they need to know ‘how’ to follow the transformation. “How”? The lessons are clear. Because of what was done, have hope and follow a different path. Because of what is now expected, listen and transform. Because of who they were (e.g. “IT”), you should honor their humble beginnings but not build newer technology on top of their legacy. Learning these lessons will prepare you for the future – your future.

All in the backdrop of an ever-growing bewildering range of integration choices. They left a manual-intensive paper-based model behind, but never reached the promise land of automation, technology, and a new style of IT that was to save them.

• Strengthening governance
• Standing up Enterprise Architecture
• Implementing an Application Portfolio Management capability
• Aligning current business climate, consumers, and emerging business climate
• Transforming your technology post-merger / acquisition
• Responding to radically different business models by new market entrants, using IT in new and threatening ways
• Developing more knowledge rather than more information

It’s a tremendous challenge to lead transformation. As portfolios grow and become increasingly complex, conflicting needs and plans arise. Look for ways of sharing the load so that others may leverage their abilities in support of the transformation. Focus on the positive – problems don’t have to rob you of the victory.

Challenges you may face

• Which systems should be launched? Updated? Replaced?
• So hard to figure out the current “as-is”. Business is always screaming for more!
• What’s the best environment for cloud? Should we even move to the cloud?
• Need operation software, but it’s so bloody expensive
• Which technologies meet our requirement? Meet our EA standards? Do we even have standards that need met?
• Complete automation!? No way!
• Spaghetti-like functionality structure

Defining ‘Business’ Value

“Houston, we have a problem.” We aren’t responding quickly enough to business needs. We cannot counter the disruptive influences of mobility, cloud, social media, and empowered consumers. Pressure from business leaders is increasing as you have failed to link transformation with innovation that supports their business needs.

• Are you implementing business-led innovation?
• Would you consider yourself an IT-enabled business?
• Are your business units’ ideas driving top line growth that your current systems can’t support?
• How well are you doing at reducing spending on traditional IT and moving spend to business projects?
• Is IT a strategic partner or just another vendor for the business?

Be honest. You aren’t in this alone! If you haven’t seen your main competitors in a white paper or at a recent technical conference, trust me, they are fighting the same thing. Your (and theirs) enterprise has become part of a much broader ecosystem – one that requires ecosystem-centric transformation.

You are slowly moving from legacy systems to modernized (what DOES that mean?) and mobile and cloud and unstructured data that requires increased security, information optimization, and mobility integration.

Bloody hell, no wonder you need a consultancy!

Where to start?

“Once it is obvious that the application / system complexity is a problem, focus your efforts on doing something about it, rather than further documenting the problem.” (Gartner “What is the penalty for complexity in application portfolios?” June 2010)

How can something so simple and straight forward, still be spot-on almost 5 years later?

Because, E-V-E-R-Y-O-N-E skips the basics. It ALL starts with documenting your current state!

How can you begin to invisition a future state when you don’t have a clue where you are today?

Think about it a bit, and I’ll see you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

Application Assessments Are Done WITH you, not TO You!

If I hire a consultancy to perform an application assessment / analysis, why do my application people need to be involved? Great question!

Short answer: They simply MUST be involved “.” (e.g. period!)

Longer answer: We, even us consultants, wish it were that easy – sign the SOW and go do an assessment to the client. LOL! Do I actually get paid for this kind of activity?

It’s a tremendous burden to lead transformation by yourself. It cannot be done single-handedly. As portfolios grow and become increasingly complex, conflicting needs and plans arise. No longer can one leader make all the decisions. Rather than trying to handle larger responsibilities alone, look for ways of sharing the load so that others may leverage their abilities and vision.

Enter the consultancy…

Boldness is not reckless impulsiveness. Boldness requires courage to press on and do what you know is right. To gain boldness, you must:

• Insure you have executive buy-in, from the business, IT and CXO level
• Look for opportunities to reduce complexity, reduce operational costs, and increase strategic investment
• Realize that denial, shared discomfort, and awkwardness are not necessarily persecution of your transformation vision

Without portfolio-unity, transformation becomes yet another IT project doomed to failure.

Where do I start? How do I found the journey? How do I define the path?

OK – you are at least asking the correct questions! It is not a membership requirement in order to be a part of any transformation. Organizational structure is not an executive command. Do you see both internal and external problems facing your portfolio of applications? Internally: shadow IT and underground applications; complexity headaches? Outside: firm being pressured by oppressive competition and excessive client demands?

You, as a transformation leader, MUST keep your focus on what is most important – transforming the portfolio to provide the business with improved ___ (e.g. any answer is correct as long as it starts with ‘to provide the business with improved…”).

Ask yourself, can an outsider answer the following questions with any level of accuracy without input from your team?

• What does the future business look like (not just industry-wide, but specifically, to your company) so that the future portfolio is aligned?
• What is the business impact of key applications – numbers of users, usage statistics, process SMEs?
• What are the current costs of each application for support, software license costs, infrastructure costs, and so forth?
• What are the current standards, policies, and procedures pertaining to applications / infrastructure development and maintenance?
• What are the current / planned projects that may impact any transformation?
• What are the current development and maintenance productivity and performance metrics, current governance structure, policies, standards and procedures?

CAUTION: Any consultancy that tells you they can accurately identify any of the above without input from your staff – don’t hire them!

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

Developing an Application Inventory

Why start with an inventory?

• Redundant applications are difficult to identify without a complete inventory
• Difficult to make informed portfolio decisions without an inventory
• Identify stability, backlog requests, # of trouble tickets, # of annual help desk calls, most significant support issue, etc. of each
• Record labor against individual applications
• What applications are in use supporting the business?
• How well do applications map to current business operating functions?
• Which applications score best and worst for function and technical quality?
• What applications are based on ‘at risk’ technology?
• What applications cost the most to maintain? Where are the best opportunities to control cost?
• What applications should be retired, consolidated or extended?

Value of an inventory

• Even low-tech inventories can expose opportunities to reduce cost
• ID application owners – find out what people are spending their time doing
• Determine how much you’re spending on maintenance. How many developers are working on each application?
• ID application not supporting the business. Identify ‘champion’ applications – those with existing significant footprints

Inventory Do’s and Don’ts

• “Collect inventory and metrics information using automation if you can; collect it manually only if you must”, is a common best practice. ACTION ITEM: With a show of hands, how many of you have ever seen or heard of a tool, piece of software, or ‘sniffer’ than could identify:
  • IT owner / business owner’s name, phone number, office number, or email address? You know, the folks that should be in the best position to know the pros / cons of the application…
  • Detailed functional description
  • All level 3 / 4 business processes supported
  • Year first implemented / year of last major upgraded
  • Number / type / direction of ALL interfaces
  • Business users #1 complaint
  • Business risks
  • You get the idea…
• Don’t collect information for which you cannot articulate a specific need to support future strategic decisions. ANALOGY: If you were in HR, what information would you need to determine whether to RIF someone, keep them, or re-assign them? Collecting information that “might be interesting one day” will drag down discovery and turn it into an academic exercise – don’t do it!
• Approach transformation as an ongoing process, NOT a onetime event. Instituting an Application Portfolio Management (APM) capability will allow continuous strategic management of this asset – one of your firm’s largest and most expensive assets!
• An inventory is developed with significant input from your staff. Author’s Note: In 2007-8, I led an application assessment in which we interviewed / engaged over 400 people in the client’s organization
• Many existing application lists are incorporated / combined to begin a base line inventory of ‘candidate applications’

Managing an every-changing master inventory requires meticulous hands-on governance

• Combining two lists into one master list can be done relatively easily. Combining several dozen lists into one master is a significant challenge for any size team
  • Removing duplicates becomes more challenging
  • Redundancy in TLA (three letter acronyms) becomes an issue
  • Tracking each and every tidbit of information from each source list, needs to be rolled into the master inventory
  • Identifying only the new additions becomes more of a challenging as the master list absorbs more sand more source lists
  • Performing this compilation manually can become a major risk for any inventory activity. Fortunately, there is a solution.

Until next time, see you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com