Developing a Transformation Approach

In 2004, when developing out an approach for business transformation, our primary goal of transformation has been to mature the investment through addressing transformation core architecture concepts discussed such as Paving Cowpaths, improving bad data lifecycles, avoiding redundant buying, balancing compliance with aligning programs, aligning products and services directly to performance drivers, and addressing inefficiencies. Our Team was under a Northrop-Grumman Contract at the Department of the Interior. Department of the Interior had multiple representatives across the CIO and Management and Budget office functions guiding and approving the enhancements.  There were three team members from Xentity, one from Phase One Consulting Group, and One from IBM and the project included management oversight by Northrop-Grumman.

BDEV

 

The method would provide a collaborative way to bring cross-functional business representation with the architecture analysts and consulting service to walk through major analysis steps:

  • Initiating the project
  • Scoping the segment
  • Business analysis
  • Technical analysis
  • Author recommendation set as blueprint
  • Incorporate into Enterprise Plan and Portfolio

BDEV-gates

 

We knew we wanted to use architecture techniques to help, but wanted to assure architecture did not follow the path that appeared for the last fifteen years which resulted in completing the information needed to assess portfolio then serially address change.

That approach would and has not engage executive interest, and likely, give the time it takes to collect the information and map to taxonomies (which needed to be developed and fostered), the information, which is time-sensitive, thus perishable, would be stale.

The result was the Methodology for Business Transformation version 1.0.

mbt-snake

 

Lessons Learned

We used the method and applied against four major mission area blueprints, but this was a version 1.0 and we ran into several major issues – actually, we logged around 100 improvements and 8 minor and sub-minor revisions resulting in MBT 1.5. We found issues in: Enterprise Governance, OMB Functions, Change Management, Performance, CIO Office, Scoring, Solution, Governance, Cost Benefit, and General. But the largest issues were not in the analysis, but the wrappers around the method. Here are the top two lessons plus general notes summary of the over 100 improvements discovered

#1 Lesson Learned – Tick, Tock, Tick, Tock

Instead, for large organizations ($100 million to $1 billion), we knew we wanted to take a segment approach to building out the information while moving through the phases of transformation. In our first draft of the resulting segment analysis method, the transformation phases resulted in starting with Phase 3.

The clock would start ticking for the architecture as soon as a team was formed, funding for the team assigned, and the project was kicked off.

This was a major issue after the first four blueprints, as we missed the key executive steps for assigning a sponsorship concept. Meaning, the definition for success was in the eye of the beholder – the executive. We skipped the critical step of defining the sponsor and their executive level needs – were they interested in savings, product expansion? What Architecture Concepts?

 

mbt4

#2 Provide precedence-based guidance on how far to mature

We knew we didn’t want to re-invent how we develop service level maturity

In 2005, as part of looking at our transformation approach, we examined the GAO INFORMATION TECHNOLOGY INVESTMENT MANAGEMENT A Framework for Assessing and Improving Process Maturity – (ITIM) – detailing “Select, Control, Evaluate” phases of management, background on proposed processes to improve IT Investment Management. 

And for guiding the maturity for the actual capabilities, we relied heavily on IT Infrastructure Library (ITIL v3) Management Best Practices (ITIL) to help in guiding how to move from reactive service to proactive and not reach to far while gaining improvements and efficiency

mbt6

 

#3 Showing the line of sight

We needed to show clearly how the analysis and resulting work products supporting across the business drivers, and the full business value chain.

Some Enterprise Architecture experts may argue the existing Frameworks such as Zachman accomplishes that, and it does in a library function, but not in a journalism function which tells it in story mode and backpockets the work products as due diligence.

mbt5

 

#4 Change is the message, EA is just a set of tools – Get over ourselves

This moved Enterprise Architecture out of being front and center and moved the mission of the segment analysis first. EA became a supporting role, and we would attempt to actually remove EA from the vernacular. The obvious reaction is this was done because of the brand beating it has taken since 1996 when the intentions of Clinger-Cohen reduced EA into an IT compliance reporting role. It was actually more so of EA`s own culture to put EA at the center of the universe when analyzing, ideating, managing change is at the center.

In our over 100 other improvements, other areas highlighted are

  • Not enough clarity on the varying roles of Enterprise Governance
  • Most transformations have strong ties to annual Budget formulation and execution activities for example, but we didn’t align that enough
  • Aligning Calendars and timing OMB and Agency Management and Budget Functions such as Planning and Performance Management, Workforce Strategy, Acquisition, etc.
  • Change Management truly missed for guiding how to implement, assess and manage risk, developing transition management capability (i.e. a PMO)
  • Performance
  • Find ways to integrate other CIO Information Management requirements to synchronize data calls across privacy, records, security, CPIC further
  • Scoring for organizational readiness as well as including Scoring framework requirements from OMB, GAO, and the like to help improve the architecture maturity scoring
  • Improved linkage to work products and guidance that Solution architecture could use
  • Governance
  • Cost Benefit missing in guiding alternative analysis
  • General iterations on language consistency (i.e. its work product not artifact), updating templates, improving checklists, improving training and creating hands-on exercises, helping customize to audiences
mbt7

The result ended up not being a full major release, as we had yet to address cultural transformation issues and still had additional concepts to consider for linking other ways to path through the method more as an approach.

mbt3

 

The supporting toolkit for MBT is a large difference maker from whitepaper procedures or sample templates:

 

mbt1

(2008: Later note, the MBT 1.5 ended up becoming the core method and set of templates for the Federal Segment Architecture Methodology (FSAM) which continues in aspects as a basis to the Common Approach to Federal Enterprise Architecture). Two team members from Phase One Consulting Group, one of which on the original MBT team, supported this effort.

MBT has since been validated by the following organizations:

mbt2