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

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

Challenges of Any Application Transformation

Typical Challenge

Ever wish you could start over – with one application sitting on one server? Ah, the good ole’ days, huh? In today’s IT environments there is, unfortunately, no such thing as a “do over”. In reality, you will have to factor in the assets you have today (both good and bad), rejuvenate some of them, and ensure there is a unified way to integrate them all. Do you ever wonder which ones should be rejuvenated?

As Macbeth once said, “Lay on, Macduff!” Meaning? To make a vigorous attack… Shakespeare could have easily been discussing modernization…

This vigorous attack (AKA transformation) will require:

• Inventory the existing assets – difficult enough and important enough that there should be a social media solely dedicated to this task
• Determine which applications to keep, which to get rid of, and which to modernize
• Next, plan, design, schedule, finance, and deploy the various modernizations – new platforms, new data centers, emerging technologies, updated business processes, retire-decomm-replace, etc.
• Finally, seamlessly integrate ‘all this’ with systems that were kept ‘as-is’, while providing a sound application portfolio management (APM) methodology to prepare for yet the next new solutions using the next generation of technologies, that will be required to support the next generation of business needs – all that could make your current activities obsolete

It is interesting to note, although the benefits of individual modernizations are many, the synergy resulting from their combined APM-centric view of a portfolio in the context of enterprise transformation leads to agility, step-rate advances in cost savings, and accelerated value in support of your business’ needs.

What are the critical success factors?

• Immediate standing-up of a transformation team / office that has end-to-end process responsibility of delivering the transformation program – staffed by, yes, both business and IT professionals

• Full-time commitment and active involvement of business executives, not just IT. Why? Transformation is NOT, I repeat, NOT an IT project. If yours is, cancelled it immediately and reinvest the budget elsewhere, because it will fail!!!

“100% of my projects, in the last 11 years, in which both business and IT were not bought into the transformation concept, have resulted in failure. What is failure defined as? The resultant recommendations / roadmap were NOT funded or approved. 100%!”

• A communication plan – continuous, timely, and including all (good and not so good) content, scope, progress, and setbacks
• Treat transformation programs like you do your firm’s vision. You never actually achieved it fully, rather, it drives you / extents you, deeper into your future. Always pulling you forward to continuously transform. Can you begin to see the need for an APM-view of your portfolio?
• OH, did I forget to mentioned, commitment & participation from both business and IT leaders AND staff
• Availability of both the business resources and IT staffs – transformation is not a part-time job – something you do in your spare-time after your day job. Would you engage a dentist to perform your brain-surgery? Why not – both occur in your head
• Commitment and understanding of transformation methodology and approach (e.g. see ‘communication plan’)
• Leverage all existing artifacts / documentation / knowledge, and the existing gaps in all three. Yes, you do have gaps – numerous gaps. Gaps can be as telling as artifacts

• Validate all in-flight projects and their potential impact to any transformation activity. You got it – ID which to keep, which to get rid of, and which to modify (e.g. modernize) to align with your transformation

• Take a hard critical look at existing governance practices and policies, closing any gaps and / or strengthening structure, participation, etc.

Transformation is not for the faint of heart. But the payoff can be extraordinary.

Next we’ll take a long look at scope and a few common risks…

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com

How Does IT Become a Partner With The Business?

Business Partners

• Can you be a business partner at your first meeting? No
• Can you act like a business partner at your first meeting? Yes, by understanding their business…
• Do you have time to be a business partner with everyone at all levels within the business? You decide. If no… Who then?

Your business is asking,

• “Why do our applications cost so much?”
• “For what we spend in IT, why can’t we implement more changes, faster?”
• “Why does everything take so long?”
• “Why aren’t more human and financial resources available for new business innovation?”
• “What am I going to get for spending another $$$ with IT?”

You respond, “A lot.”

“How much?”

“A whole bunch!”

Point is, the business will always low-ball the amount of value, based on your past performance. IT must know the benefit to the business (articulated in the business case submitted — not just costs!). How confident are you about the benefit to the business?

If the business truly doesn’t see the value – then IT needs to change that view, because IT isn’t going to reduce their cost at the expense of their own organization. Remember, moving up the change of command – the higher you go the more ‘they’ will appreciate value — more & more & more – the higher you go. Anybody can get up the chain ONCE! But you better bring your (quantifiable) value…

See you in the future…

Frank Wood

Executive Transformation Strategist

Frankwood944@yahoo.com