The Brutality of Ageism – Has it Caught You Yet?

I recently hit the big 6-7! Yep, I’m 67.

During the Woodstock era, layoffs were handled by reverse seniority. It was last in, first out, so the more senior workers kept their jobs. The argument being they were more capable, had more experience and know-how, done it before, etc. Today, we see a transition to age discrimination, as newer workers are allowed to stay on while more costly, older workers are let go.

I was WFR in February. I was the oldest in our group. Matter of fact, they laid everyone off that was in their 60s, keeping one 60+ as a token.

Age, particularly acute in the tech industry, is the silent career killer. While companies openly wrestle with the lack of racial and gender diversity, they typically refuse to disclose the average age of their workers. In 2016, the median age of an American worker was 42. Yet at FAANG-type companies – Facebook it’s 29, Apple 31, Amazon 30 and Microsoft 33, Google 30, according to research firm PayScale.

What do you see when you look at The Boring Figure below?

TheBoringFigure

A young recent graduate FAANG-type employee, or an experienced seasoned programmer? This illustration is an accurate representation of the ageism phenomena because the two different images are interpenetrating one another with no formal dividing line. In other words, when (notice, it’s ‘when’, not ‘what’) is it exactly, that someone crosses the age-discrimination line?

As the Boring Figure illustrates, there is no formal dividing line. You won’t realize you’ve crossed it until…well, you’ve been cut loose, or didn’t get offered the position you interviewed for.

Job applicants in their 40s and 50s shave years from their LinkedIn profiles and resumes by truncating their job histories to appear younger and improve their marketability in the age-conscious tech industry. We’ve all done it.

Online Applications

If you’ve filled out an online application recently, you’ve noticed in the ‘optional’ sections of a typical application, they ask questions around:

  1. What is your gender?
  2. Do you identify with LGBT / Two Spirit Community?
  3. Do you consider yourself to be an indigenous or aboriginal person?
  4. Do you consider yourself to be a member of a visible minority group? Should ‘hair color’ be listed? It’s visible.
  5. Do you have any disabilities? You actually have to sign and date your response for this one.
  6. What is your race / ethnicity? Two or more? I filled out one online application for a multinational, and this question ONLY applied if you were in the U.S.
  7. Hispanic or Latino?
  8. Do you identify with one of the protected veteran groups?

Many of these online applications come with a disclaimer like “…is an Equal Opportunity Employer, and we hire, promote, and reward employees without regard to any difference unrelated to performance.” Don’t these disclaimers imply there is no right or wrong answer? In other words, they’ll accept you regardless.

Notice the one question they never ask: “How old are you?” Car rental companies and airlines asked you when booking a rental or a ticket. Why not job applications? Of course, whether you answer or not would be completely voluntary. Yep…

Since when is a person’s ‘age’ not considered ‘equal opportunity’ and / or diversity?

Look at the 1888 German postcard, “My Wife and My Mother-in-Law”. What do you see?

WifeAndMotherInLaw

di·ver·si·ty (dəˈvərsədē, dīˈvərsədē) noun, the state of being diverse; variety. a range of different things.

Age discrimination accounts for nearly a quarter of the overall complaints filed with the Equal Employment Opportunity Commission, which also pursues charges of discrimination against a job applicant or employee on the basis of a person’s race, color, religion, sex, national origin, disability or genetic information.

Even as the work force has a larger and larger number of older employees, one of the principal tools to fight such discrimination, the Age Discrimination in Employment Act — which Congress passed a half-century ago — may not be up to the task. Based on a 2009 Supreme Court ruling, proving age discrimination became more difficult legally. Plaintiffs have to prove that age discrimination was the prime, or motivating, reason for demotion or dismissal.

When compared to your gender, visible minority group, disability, or race, how do you prove age discrimination one way or another? You don’t! Just look at the below illustration “Husband and Father-in-Law”. Age discrimination is in the eye of the beholder. Who’s the beholder? The company you work for, or the company you interviewed with.

HusbandAndFatherInLaw

I give it up to Bearing Point. They are at least honest and ask your birthday on their online application.

Older Workers are Deadwood

Comments like these don’t carry the same stigma as remarking about someone’s sex or race. “Diversity of experience and thought is critical for any organization, industry or society to thrive,” says Todd Thibodeaux, CEO of CompTIA. “Tech will have a projected shortage of 1.8 million workers by 2024. Older, re-trained workers, women and people of color need to be part of the future of tech.”

Imagine, if you were born in the 1990s, you may be too old by 2024. Gives you dry mouth, doesn’t it?

Recruiting agencies, for example, are using automation to screen out applicants over 40 without questioning their age. They assume you won’t work hard, long hours, and have out-of-date skills. Silicon Valley employees, are getting older and staying in the workforce longer yet ageist comments increasingly are being directed at younger and younger workers deemed “too old.” It used to be workers in their 40s were treated as over-the-hill; today, it’s employees in their mid-30s.

Most company websites have employee pictures that insure inclusiveness – Hispanic, Asian, black, white, brown, men and women. But very rarely a person with gray hair (OK there, I said it…).

How many people, would you estimate, are available simply because they are in their late 30s, 40s, 50s, 60s, or 70s, and undervalued? The movie Moneyball is the story of Oakland Athletics general manager Billy Beane who attempted to build a winning team by using mathematical rigor to find and hire undervalued players.

Goldman Sacks plans to begin using a personality test as part of its hiring process to figure out what makes prospective candidates in the industry tick. They are trying to figure out what makes great traders great. Does it make sense for firms to develop a standardized assessment tool that results in casting a net over a larger section of the population? Aren’t they hiring performance, rather than segmentation?

Warning Signs

  • On your annual performance review, you’ve been moved down from “exceeds expectations” to “meets expectations” for no apparent reason.
  • You or your spouse have had a serious (e.g. expensive) medical condition recently.
  • You’ve been rewarded for your success, and therefore, make more than most everyone in your group or on your team
  • A marked acceleration in requests for you to ‘cross-train’ younger members of the team
  • Quickened implementation of the off-shoring model
  • Re-engineering / consolidation of job titles, groupings, and pay structures by HR
  • Increased focus on hard-to-measure skills such as leadership, communication, interpersonal
  • Discharged co-workers are never allowed to re-apply

You Cannot Hide Your Age from the Onsite Interview

Have you ever nailed a succession of phone interviews, moving the process forward until you are invited for an onsite interview? Once onsite, that interview goes smoothly, only to hear back from the HR recruiter that they were looking for someone with expertise with a completely different set of skills – skills not listed in the job posting nor highlighted in your CV.

This happened to me a couple months ago. I was interviewing for an ‘application modernization’ position at a major consultancy. During three phone interviews, I was asked to role played, envision the future, to cover specifics of how to access a large portfolio of applications and then gap that assessment to a perceived future state. The feedback couldn’t have been better. Then came the onsite interview. Once again, I discussed application modernization in detail, drilling deep into areas such as operational TCO models and a vision of maturity models, etc. Wait for it…

Then came the feedback from the recruiter a few days later, “They are looking for someone who can articulate a vision for how CMDM, monitoring, and ITSM tools can improve IT.” Say, what? My initial thought was, “that’s not the position I interviewed for.”

It’s alright to fall into various ethnicity groups like in the illustration, “Indian Chief/ Eskimo” or LGBT in “Mother, Father, Daughter”.

IndianChiefEskimoMotherFatherDaughter

But, ‘too old’?

“Old man look at my life, I’m a lot like you were.

Old man look at my life, 24 and there’s so much more…”

“Old Man” by Neil Young

(Released when he was only 26)

If you look at my profile and see anything resembling yourself, you may be in trouble. What is in your resume that says, “I’m 35+ years old?” Unfortunately, it does make a difference.

Woody1975WoodyToday

Trust me when I say, “I’m still the same guy…”

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Advertisements

Cloud – Are You Ready?

Today’s Challenges are Not the Same

Today’s plethora of technology advances with their bewildering cornucopia of choices, why would they be the same? Your company wasn’t born digital. How in the Sam Hill do you compete with those who were? Their speed and agility are simply staggering – the way they innovate the customer proposition keeps you awake at night. You must be thinking, “Oh, how I wish our firm had that ability.”

Is Cloud the Answer?

Let’s take a look…

You are facing hundreds, or maybe even thousands, of applications built at different times, in different languages, by different teams in different geographies to meet different goals. Yet, they all need to be evaluated before migration to the cloud can begin – but how do you do that? In addition to a profound understanding of your application portfolio, this often requires an equally deep knowledge of the existing infrastructure and the cloud resources that would replace existing FTEs, to name but two.

Here is a basic check list of the information required before making cloud-centric decisions. Note, that this information is required for each and every application that is on your cloud-candidate list (more on that later).

Portfolio-wide:

Do you have a complete up-to-date inventory of all applications? If you don’t, this in itself is daunting. A few years ago, I led a team of consultants for North America’s largest utility — it took us 6+ months, interviewing 400+ employees, uncovering 43 out-of-date incomplete lists to compile a master inventory — which had never existed prior. At one point, we had 50,000+ app-candidates with which we started the ardent task of deduping, removing junk (server names, project names, interfaces, websites – you name it…), before we validated approximately 1500 applications. 6 months x 10 consultants x 40 hours / week = a (very) large investment in one of their firm’s largest and most important assets – the inventory of applications. And you know something? The client admitted THE most important deliverable of the entire project was a simple, yet complete, inventory of their current state. He had realized they couldn’t move forward without it. Lesson learned: DON’T SKIP THIS STEP! Admittedly, it’s not very sexy, but it is mandatory.

What is the benefit of ‘on-demand access’ to an ‘elastic pool’ of shared computing assets — applications, servers, storage, networks? What, literally, does scaling up or down as needed on a pay-per-use basis get your firm? If you can’t quantify the benefit to the business, you shouldn’t proceed. Why would you?

Can you “quantify” these benefits that come from cloud?

  • Greater flexibility
  • Both hard & soft savings
  • Someone else manage your HW/SW, lowering risk
  • (Dramatic) reductions in support staff à more FTEs available to focus on value-add innovation
  • Efficiency – only pay for what you use, freeing up funding for additional investment
  • Reduced support costs via a platform for automated, self-service IT

Are you prepared to manage applications in the cloud? How so? What needs to change? How will you develop and test applications in the cloud? Should you outsource that as well? Can you envision how to connect your end-users to their applications once in the cloud?

The SO WHAT test:

  • Organizationally, are you prepared to share resources across the enterprise? Cloud will require you to do that. From a HR perspective, are your IT performance metrics extendable to include public providers? If no, what’s the effort to make them so? Should they be the same? What will be the impact on existing roles in your IT organizations? Will your employees deem this cloud-thing as a demotion? More effort on their part? Will they want more money? More training? Who will leave the organization? Why will they leave? Bottom line, you must prevent any migration to the cloud from becoming a demotivating influence to your current employees.
  • Your business may be adopting cloud ‘x-times faster’ than IT. Do you know why? Is it OK? Can you get both organization back on the same page? Should they even be on the same page? If yes, what’s the value to the enterprise?
  • IT core competency needs to shift from being (just) providers to being brokers. OK, we’ve all heard this, but does a relationship exist between your IT organization and operations to allow this to become reality? If it doesn’t, cloud certainly is not the solution to change the relationship.

Individual Applications:

Which applications are the ones that anyone within IT or the business feels needs to be retired in the next 2-3 years? Obviously, these applications shouldn’t be considered cloud candidates. Cloud isn’t the solution for all applications. Do you have a method to breakdown your inventory into two lists? One, keep supporting in-house with existing staff, and the second – the cloud-candidate list.

  • What’s the criteria to develop each list? What are the deciding attributes? What is the weighting factor for each attribute? Is each weighted appropriately?
  • Who developed the criteria for attributes and weightings? How long ago? Is it still valid today?
  • Who decides when to add new criteria? To remove old criteria?
  • Who can override any scoring mechanism and make a rogue ‘executive management’ decision?
  • What applications need a quicker response time? Why?
  • Which applications provide enough business value that the front-end investment to move them to the cloud is a sound financial decision?
  • Which applications, once cloud-enabled, will still fit the way you do business? Which will do it better?
  • Which applications require the best stability? Reliability? Why? What is the impact on the business if they don’t have it?
  • Which applications, and their data, must be secure? What’s the business reason for the security? What’s the impact to the enterprise if there is a breach?
  • What is the impact on existing integration points with other applications? Does the integration need upgraded? Is the business case strong enough to cover these additional upfront costs?

So…What’s in it Really for the Business?

Remember, that pesky bunch that you support? Let me put it out there… Do NOT, I repeat, do NOT move 1 application to the cloud without asking the business what’s in it for them? Ask them, “what will the cloud provide you that you currently aren’t experiencing today?” Then listen intently…

Simply put, if you cannot articulate the ‘value’ business will receive in answering ‘the why’ moving an application to the cloud makes sense – don’t move it! Period, end of story, nada, move on to plan B…

Make sense? Applications are the key to greater efficiency, growth-oriented innovation, and IT cost reductions. These should continue when leveraging the cloud at any degree.

Questions that Many Clients Face

  • Can the cloud provide value to my application portfolio during a merger, acquisition or divestiture?
  • How do I determine if my legacy application environment is simply too old for transformation?
  • Will the cloud help translate maintenance spend to supporting the drive towards new innovation (read – business value)?
  • Will there be an uptick in complexity? How do I manage that while achieving more agility? How do I insure alignment with my business teams on meeting their future business needs?
  • Will the business need to change? (Tell me, oh please tell me, that the business was involved in the solutioning and decision making process – please) If yes, what impact does that have on my IT organization?
  • Do I start with the “problem children” in my portfolio or save them for last? Maybe just retire or replace them
  • What about my in-flight projects? They have already been approved. I can’t afford to finish all of them and spend on new projects to the cloud. How do I decide which?

So, Frank, Am I Ready for the Cloud?

Clients ready for any application transformation typically exhibit some of these driving forces

  • Struggle to align with the business from a strategic, capability, or an enabler point-of-view
  • Managing a (very) large number of applications and trying to figure out the right choices to rationalize to a smaller number
  • Struggling with an ERP implementation or other significant modernization project(s) that are not progressing as desired
  • Dealing with a lot of change within the business (e.g. M&A, markets, products, services, desire to globalize and / or centralize operations)
  • Changes in leadership, new CIO trying to put arms around what they have and how best to manage the business’ expectations while staying within an ever increasingly stringent budget
  • Consolidation in data centers and considering if it is the right time to modernize / rationalize / move applications at the same time

On the other hand, clients thinking about application transformation but are not really ready exhibit restraining forces like:

  • Little or no understanding of a strategic direction from either a business or IT perspective
  • Specific direction with regards to their infrastructure, data center, or network with no desire for functional or application change
  • Maturity of organization, governance, enterprise architecture, and / or business participation is low or non-existent
  • Too few FTEs being asked to support far too many applications
  • People funding enterprise applications not rational about which applications truly provide the most value, resisting any effort to modernize. Remind you of a car owner and their favorite old car?

Which of the above lists describes your current situation?

Here’s Your Plan of Action

First and foremost, understand your business’ goals! You’ve heard it before, right? But it’s true, your organization’s strategies and goals should define their future state. In addition, define your target architecture, along with a cloud strategy that supports the business goals. ANY effort, MUST satisfy that business direction.

(DON’T SKIP THIS STEP!) Build a full inventory of your applications portfolio. If you don’t, STOP right here and don’t read any further… You need to clearly understand the application technologies you’re starting with. Including such attributes as (1) the application architecture; (2) integration with, and dependencies on, other applications and data; (3) application technologies and resources; (4) the infrastructure on which it runs today, and; (5) all unique aspects of application operations and business service delivery that may exist.

Oh, and don’t forget the parts you can’t see:

  • Include inventorying the ‘shadow IT / underground applications’. May take twice the time but it might just uncover areas of need that a cloud environment could address.
  • Avoid migrating dead or duplicated code
  • In-flight projects may be an accelerator or a brake to any transformation – determine which is which for each major project. Don’t be afraid to cancel or postpone some.

In addition:

  • Identify all the business issues that impact (or may be impacted by…) what you can do with each application. Items such as regulatory / compliance, security, geography differences, vendors and partners who provide any type service or support
  • Once you have cleansed an appropriate application cloud-candidate list, develop a transformation strategy to the cloud for each. This should include identification of the target landing zone for each.
  • Review current business strategies and goals down to level-3 business process levels supported by each application, focusing on current, as well as future state
  • (Obviously) assess each application’s suitability to run in a cloud environment. Make the assessment process repeatable and use it consistently across the portfolio
  • Develop a project plan that incorporates a seamless transition to running the application after it’s been migrated to a cloud environment. Some may require running in parallel before the final cutover.

So…is cloud the answer for your current situation?

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

What Is an APM Team and Why Do I Need One?

An Application Portfolio Management (APM) team should consist of operational team members who will utilize the APM Playbook (see my previous blog post 4 March 2017) to prioritize transformation efforts.

Ok, you say that makes sense. So far so good. Then you say, “my very competent governance organization should be able to operationalize the APM Playbook.”

I say, “Fine, let’s look under the hood at that suggestion for a moment.”

Governance – that holistic approach needed to manage relationships, decisions, and actions across all pillars, segments, and business units. Strategically, that would include items such as:

  • A model encouraging performance improvement while ensuring conformance to principals and processes aligned with strategic direction and decisions
  • Policies and standards linked with how IT will deliver capabilities and support business processes
  • Roles, with accountability and responsibility, for decisions required to deliver and manage IT products and services

Tactically, you would expect this same organization to provide:

  • Detailed IT process definitions and interactions
  • Defined IT organization design and aligned demand requirements
  • Measured objectives for managing / delivering IT products and service
  • Defined capabilities and value for IT services and processes
  • Common decision model
  • Managed Risk

Who’s on First, What’s on Second, I Don’t Know on Third

You say, “I agree with everything you’ve presented.” I respond with a knowing smile…

“So, those individual governance teams that exist within all the pillars, segments, and business units are performing the exact same activities and delivering the exact same projects, all at the same time, in locked-step for the good of the firm – all the time?”

Your eyes drop to your computer screen checking for a discussion-saving email or IM.

“Never any duplicity or redundancy? Expectations and impacts are always in perfect alignment? Each individual decision within a pillar never results in inconsistent, fragmented decisions and capabilities in other pillars or segments? Is your firm that siloed that can actually happen? Documentation and communication plans are always exemplary so as to be shared with other business units?”

With a crease over your eyebrow, you look at me with your own knowing smile.

I’ve got your attention now…

Remember What an APM Playbook Is

An APM Playbook provides guidance to optimize a firm’s application portfolio and achieve measurable business results by shaping the Playbook content with:

ShapingAPM

Why an APM Team?

Portfolio-wide responsibilities and oversight to insure:

  • The optimal number of applications to support the business?
  • Which applications will be the “go-forward” applications?
  • Metrics to support strategic decision making
  • Enhanced decision making capability based on detailed attributes
  • A strategy to properly align an application portfolio with the business strategy

This level of specific responsibility over an enterprise portfolio of applications is not within the scope of the broader governance model.

Membership on an APM team is NOT a Part-time Gig

Members don’t keep their ‘day jobs’. Any APM strategy, Playbook, Framework, or Team is not a quick fix. It is a new way to view a portfolio of applications — as one of your firm’s largest and most important assets. Hence, it requires this type of stewardship and oversight.

Design, align, staff, and implement the APM Team with methodology / metrics for planning and execution of the APM framework.

  1. Engage an external transformation consultancy in an oversight capacity to insure team is staffed properly, develops proper mission and goals, and identify communication standards
  2. As an example, validate the following roles: Team Sponsor(s); architect(s); business owners / users; financials; Management of Change (MOC); others…
  3. (Probably the most important) Develop HR standards and embed these new job role(s) into existing career paths. Ensure that after an employee rolls off the APM team, that they are rewarded with a higher position that which they left to join the team.
  4. Transfer employees into new roles and staff team
  5. Launch Team, communicate to organization
  6. Establish measurable business-driven goals & decision criteria

Initially, team’s focus should be on:

  1. Oversight of investment, and cost (total cost of ownership of portfolio) management
  2. APM risk and compliance, alignment with existing governance structure / policies, etc.
  3. APM processes and standards
  4. Communication with executive committee, governance organization, etc.
  5. Managing metrics and measurement reporting
  6. Maintaining the prioritization of high priority initiatives, and ensure each is planned and resourced with required skills
  7. Provide oversight to the APM strategy and identification of additional transformational projects and their recommendation
  8. Develop succession planning for APM members – cyclic roll-off / roll-on after 1-½ to 2-½ year assignment for all members. Members should be responsible for identifying suitable replacement for themselves

The APM team is shaped by a set of guiding principles (e.g. Team Charter)

  • Deliver as much real value as possible as quickly as possible
  • Time the delivery of capabilities so that it will be of immediate benefit to the user community
  • Minimize possible disruptions to the organization
  • Balance the needs of many groups within the firm
  • Ensure the Framework (e.g. Playbook) is implemented aggressively and the results highly attainable

Preferred skills for APM team members

  • Strong vision – ability to communicate goals and direction in a compelling manner
  • Strategic thinking – understanding of business processes
  • Strong leadership skills
  • Ability to make decisions in a timely manner
  • General understanding of information technology support relative to the business
  • Help the team diagnose its leadership needs; identify individuals who could counter-balance the team’s weaknesses – energized by working together
  • Coordinate activities to accomplish a common goal
  • Focuses On high levels of output
  • Work at confronting and working through differences – stride towards synergy

Organizational considerations for APM team members

DOs

  • Mid-level to senior employees that are known within the organization
  • Basic Understanding: Leadership is learned / shared matter
  • Basic Understanding: Leadership can come from anyone in team
  • Team decisions are essential (“None of us are as smart as the rest of us”)
  • Equal representation between IT and Business across multiple layers within the firm
    • Number of members
    • Equivalent org chart positions

DON’Ts

  • New employees / junior employees (APM is not an entry-level team)
  • Destructive debater
  • Emphasis on analysis and counter-analysis
  • No attempt to coordinate ideas
  • Over-focused on task roles

Symptoms of a cohesive (healthy) team

  • Democratic process
  • Full participation
  • Consensus decisions
  • Conflicts worked through
  • Very productive / satisfying
  • 1/3 To 1/2 time spent planning

Symptoms of an unhealthy team

Divergent Group (Unhealthy)

  • Leadership Void
  • Too Cautious
  • Voting
  • Conflict Avoided
  • Very Unproductive / Dis-satisfying
  • Do Not Complete the Task

Fragmented Group (Unhealthy)

  • Autocratic leadership
  • Quick decision
  • Little participation
  • Conflict ignored
  • Somewhat productive / dis-satisfying
  • Usually <1 min planning

As Peter Senge stated in his book, The Fifth Discipline, “Organizations break down, despite individual brilliance and innovative products, because they are unable to pull their diverse functions and talents into a productive whole.”

When implemented correctly, APM Teams can be one of a firm’s most strategic driving forces.

APM Typical Results

APM_TypicalResults

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

What Is an APM Playbook and Why Do I Need One?

An APM Playbook (e.g. Framework) defines a method to score each application and their health as a portfolio by assessing strategic attributes such as an application’s age, supporting technology and skills, available vendor support, and the value an application provides to the business. Using these criteria, business decisions can be made to determine whether specific applications should be kept, updated, retired or replaced.

An APM Playbook Should:

  • Define a standardized approach to measuring the risk of technology obsolescence
  • Create measurement criteria for evaluating operational risk of applications
  • Create a process for justifying investment in technology modernization effort
  • Consider the complexity of functional and / or integration changes

This framework should consider business architecture, technical architecture and operational concerns when evaluating and prioritizing application modernization initiatives. This ensures future investments have a strategic alignment with corporate initiatives.

But First, Let’s Back up a Bit – Just What Exactly is APM?

APM is a management-level discipline – a fundamental, ongoing discipline, not just a one-off exercise to support transformation.

BUT Why, Why APM?

  • Determine what is the optimal number of applications to support the business
  • Identify which applications will be the “go-forward” applications
  • Decide if the focus should be on business innovation or on the efficient management of application assets. Or both

So, what do I REALLY get from APM?

  • Strategic metrics to support decision making
    • How consistent and standardized does the firm wish its business processes to be?
    • What is the optimal number of applications to support the business?
    • What are the operational costs of each application?
  • Enhanced decision making capability
    • Which applications to keep, which to get rid of
    • Which apps should be invested in, which apps are too far gone to invest in further?
    • Projecting the total spend for the next 3-5 years, then perpetuating these projections very much like a firm’s vision statement. What? In other words, you never want to achieve your vision, you always, constantly want it to stretch you into becoming even better.
  • A strategy that addresses numerous issues that a firm needs to properly align an IT strategy with that of the business

The Value of APM and the APM Playbook

valueofapm

An APM playbook should, at a minimum, include the following sections:

  • Executive Overview / Introduction
  • APM Plan
  • APM Lifecycle
  • APM Governance Model
  • Analytics Framework
  • APM Decision Framework & Decision Events
  • APM Capability Management
  • How to Mature the Playbook

With this level of detail, you can increase effective communication; increase the speed of the implementation of a transformation roadmap; and increase responsiveness and effectiveness. In addition, and more importantly, integrate the process between the transformation initiatives and existing governance / EA standards and policies, such as:

  • Single governance review for all transformation projects on the roadmap
  • Approval for all additional projects not on initial (e.g. master) roadmap. No project gets approved without integration into the master roadmap as it’s the “single source of truth” so to speak…

An APM Playbook should support

  • Identification of business areas affected by application consolidation
  • Assessment of the degree of variations across application versioning
  • Mapping of current applications, with their basic cost and quality data, to business processes
  • Obtaining management approval of portfolio standardization goals
  • Deciding the optimal number of applications to support the future state
  • Assessment of the existing apps (e.g. a 1-time application rationalization analysis)
  • Performing an operational cost analysis of individual applications
  • Development of a business case for the transformation roadmap
    • Business benefits, OpEx savings, CapEx of modernization, cost of de-commissioning and subsequent OpEx savings, etc.

At the core of any Playbook is an analytics framework as well as a decision framework and decision events. The analytics framework must include a risk framework, analysis linking risks to application dispositioning, and strategic attributes.

Leveraging the analytics framework, the decision framework must include the decision criteria, disposition prioritization and types, maturity, and linkage to the APM Lifecycle. Finally, the decision events include event scenarios and scenario examples.

It’s so easy to think, our people have navigated successfully through one transformation, so perhaps it won’t be as hard to sign them up for another one.

Oh, oh, I almost forgot — if you have an APM Playbook, do you need an APM Team to implement?

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

INSURING Successful Application Transformation

Oh, the “BIG if”. IF (and trust me, this is big – really really BIG) you are going to embrace application transformation, it goes without saying you want to do everything you can to insure success, correct?

What Outputs Are Key To Insure That Success?

  • Produce a rationalized portfolio that will support a broader strategy of the enterprise?
  • A life cycle for the applications mapped to the future, enabling the modernization of the portfolio?
  • Financial model to insure applications are contributing to the success of the organization?
  • Application transparency providing the ability to advise the business rather than just??? (fill in the blank here)
  • Business capability based on value t-o   t-h-e   b-u-s-i-n-e-s-s, current condition (health), and level of resource consumption which forms the informational base that enables rationalization?

Yes, yes, yes, yes, and a resounding yes. A good transformation plan addresses multiple issues that the enterprise needs to properly align IT with the business. Note, I DIDN’T say, “align the business to IT”. It should include sourcing, platform migration, delivery models, governance, life cycle management and process integration, and…

Enterprise Coaching That Includes:

  • Improved focus on transformation
  • Organizationally, insuring people are ready for transformation
  • Developing a vision for how technology will transform the business
  • Identification of all stakeholder issues

Risk Management

It is very appropriate to identify a single set of risk criteria across the scoped applications to be transformed.

  • How consistent and standardized does your firm wish its business processes to be?
  • What is the optimal number of applications to support the business processes? One (1) may have been realistic back in the 80s but not today. Thousands are too many.
  • Which applications will be the “go-forward” applications? No need to replace all of them.
  • Should we focus on business innovation or on the efficient management of IT assets?

In addition, consider these always-present risks:

  • Critical assumptions may not prove to be valid
  • Shifting enterprise priorities may redirect the project scope and / or critical resources
  • Business resources may not available, and to the extent required – yet another reason to get the business involved from the start. Transformation is something you do WITH the business NOT to them.
  • Scope of the project, along with other business and IT commitments, may be unmanageable
  • Desire of business leadership to alter the current state

The Risky Nature of Avoiding Risk

What has changed? To be successful, you have to out-innovate and out-execute your competition and that means moving faster, entering new markets, being more accessible to clients, and launching new products. In may mean increased risk = increased success.

Information is an asset that, like other business assets, is essential to an organization’s business and consequently needs to be suitably protected. This is especially important in the increasingly interconnected business environment. As a result of this increasing interconnectivity, information is now exposed to a growing number and wider variety of threats and vulnerabilities. As you share more information with your employees and customers alike, risk increases. As you leverage social media, risks go up. New markets? New risk.

There are two types of people. Those good at growing things that are already working. They suffer from xenophobia – the fear of the unknown.

Then, there is the transformation-people. Those that take greater risks and transform things that need it. Imagination – transformation needs that. For these folks, the world doesn’t change in front of their eyes, it changes behind their back – because of what they transformed.

Effective Communication During Transformation

  • Increases speed of implementation
  • Increases responsiveness and effectiveness
  • Enables a single transformation oversight team, using standard processes, thus eliminating inconsistencies in projects
  • Integrates processes between transformation initiatives and existing governance and EA standards and policies.
    • Single solution governance review for all transformation projects
    • Approval for all additional projects not on initial roadmap
    • No project gets approved without integration into the transformation roadmap – the master / single source of truth
  • Get opinions? Yes, but then decide, then move…

Move FAST!

Gartner says that this year (2017), 50% of total IT spending will be spent outside the formal IT organizations. IDC adds that 80% of Enterprise IT organizations will commit to hybrid cloud architectures.

Need to Identify:

  1. Objective(s) that benefit the business
  2. ID Dimensions of risk (business suitability, compliance, security, etc.)
  3. Define inputs / outputs
  4. Identify key roles and responsibilities

What Results can you expect?

  • Improved performance
  • Reduced costs
  • Rationalized portfolio
  • A future-proofed IT
  • Reduced risks

Easy? No. Mandatory? Yes!

It’s so easy to think, “Our people have navigated successfully through one transformation, so perhaps it won’t be as hard to sign them up for another one.

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

Value Migration and the Impact of a Journey into Application Transformation

Many organizations attempt transformation and use transformation-centric language, but they really don’t believe in it or strive for it. Because? They don’t see the value in it. Profession doesn’t always mean possession. How do your strategies match with your conformity to take the journey?

One of the most difficult lessons to learn is that transformation is inevitable. It is above all those other things – M&A, organizational changes, new leadership, new products / services, new markets – OR, maybe it’s because of all these things? Lack of transformation kills a firm’s value delivery, thus limiting the power and authority of the entire enterprise. Those who live in the upper branches of the organizational tree, with relatively comfortable financial situations and high degrees of autonomy, find this difficult to understand. While we may feel as though we are free to do what we please, transformation is sovereign over every departmental plan and action.

Your company has entrusted to you, value creation. Have you, in turn, trusted transformation to take you to the future of value creation? It should be THE top priority.

As priorities evolve, you will say, “I don’t care about our historical abilities to ____?_____. Our business has changed, our needs have changed. What I really care about is _____?____. What I will pay a premium for is _____?____.

You’d better be in a position to fill in these blanks. The pattern is clear – when needs (think – value migration) are emerging, the business looks to transformation. When needs mature, business looks for low cost and stability.

Emotionally, it’s easier to change when you’re hemorrhaging

What’s on your radar screen? If your executives are worried about competitors’ moves, customer’s demands, or market shifts, they very well better be worried about how to transform the plethora of applications to support these changes – starting today.

As Andy Grove, former CEO of Intel, said, “There is at least one point in the history of any company when you have to change dramatically to rise to the next performance level. Miss that moment and you start to decline.

Transformational denial can blind your organization.

Take a look at this quote from a recent key executive, “We found it very very hard to face up to the decision. Financially, it should have been easy. In retrospect, it should have been easy strategically too. Yet, we, the management, were at each other’s throats over this.

Sound familiar?

Success can trap you. The more successful you are as a company, the more difficult it is to transform into something else. To take advantage of the opportunities in front of you, you must transform. And your portfolio of applications had better be nimble enough, agile enough, scalable enough, integrated enough, and cost effective enough not to get in the way.

The time to transform is to do it while your core business is still strong enough to see it through. Need proof? Take a look at the big legacy technology companies today. Ask yourself, “at what point is our decline irreversible?

One of the best ways to influence the ‘we’ve-always-done-it-this-way” group is to work diligently and responsibly on the transformation journey. Always representing the strategy in a positive light – increasing the awareness for the need for the journey. Your critics will have a difficult time finding legitimate arguments against it.

Can you wait?

46 years ago, in 1970, the market capitalization of (all) the world’s companies was $929B. 23 years later, in 1993, this grew to $12.6T. Today, the capitalization of the world’s 100 largest companies stands at $16.2T.

Are you on the verge of forgetting? The longer you wait to transform, the greater legacy can choke an enterprise. At some point, firms develop institutional-Alzheimer’s. Wait long enough, the damage will be so complete that nothing you do will generate value of any consequence. You could find yourself on the short-end of any digital business strategy – a death sentence in today’s environment.

Begin transformation by asking, “What journey should I be developing today?

Justification

We’ve all heard them and experienced them. The eight common excuses for not transforming

  • “They” (another BU, department, region, etc.) don’t deserve help. They got themselves into this current state, let them get themselves out
  • The call for transformation applies to others
  • We don’t know of any other companies doing this
  • Competing needs, goals, and strategies
  • Any money invested in transformation with be wasted or re-appropriated
  • We may become involved so deep we’ll become victims ourselves
  • Don’t know where to start, and don’t have time
  • Any effort won’t make any difference

CostOfAdditionalApplications

Be smart, have a plan…

There is no right or wrong answer to the transformation journey or the value it can generate. There is more than one road to the future. Remember baseball legion Yogi Berra’s line, “If you come to a fork in the road, take it.”

The Transformation Suitcase

What to put in your enterprise-wide suitcase for the eventual journey in transformation? At first thought, you don’t know what to take. Here’s an idea: Put in everything that is in the back-half of its life cycle. Put in all the legacy AND lack of technology-currency you can find. Also, all the BU-centric solutions that were implemented during those budget-lean years. Plus all the stand alone applications with manual interfaces. In other words, you are focused on all the technologies that have zero value left to offer the organization.

Hopefully, you will identify many things to put into your suitcase.

As important as your transformation journey is, you want, and need, the enterprise’s backing. On your own, you have neither the ability to fulfill nor the power to disrupt the momentum of legacy. Take a look at the following current-state application architecture of one of North America’s largest utilities. Ask yourself, “Is this model sustainable?”

CurrentStateAppArch_PGE-Example

Can you envision doubling or tripling this complexity? Support staff? Operational cost? Consider, this graphic represents only 20% (top 300 of 1,500) of the application portfolio with:

  • “Put-out-a-fire” architecture
  • Point fixes that don’t fix problems
  • Bypassing the middleware because it’s “cheaper”
  • Departmental IT (e.g. shadow IT)
  • Bewildering range of integration choices
  • Functional redundancy
  • Prevalent manual processes

Implementing the Plan

Implementation of your transformation journey is critical. A roadmap must be approved, executed, and governed. You are either “mixing mortar”, “filling the cracks in the wall”, or “building a cathedral”.

You decide.

Roads? Where we’re going, we don’t need roads…

See you in the future…

Frank Wood

Executive Transformation Advisor

frankwood944@yahoo.com

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 commentmake 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