“As-Is” to “To-Be” Transformation & Transition Planning
Researched and Developed Especially For
Participating Agencies
WASHINGTON STATE DIGITAL GOVERNMENT APPLICATIONS
Academy
May 2001
in the
Transformation Involves Transformation Involves Transformation Involves Transformation Involves Transformation Involves
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 2
Dynamic & Iterative Approach
2
To-Be
Chunking & Prioritizing Releases
1 As-Is
Product Released
3 Transition Plan
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 3
3 Galvanizing Points Involved In Transformation
Your current / existing “As-Is” architecture The desired / targeted “To-Be” and
Transition
Plan
We’ll be going over each area in some detail
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 4
2
Outcomes for Today?
1
To-Be
Chunking & Prioritizing Releases
3
As-Is
Transition Plan Product Released
Understand how Transformation:
involves your “As-Is” and “To-Be” is applicable for any IT or Business application entails understanding the Relationship between things
Understand stages and activities involved in Best Practices approach Understand why this approach provides a critical success factor
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 5
2
Defining an Approach for Transformation
1
To-Be
Chunking & Prioritizing Releases
3
As-Is
Product Released
Transition Plan
Our Transformation lifecycle involves and develops five types of deliverables
1. 2. 3. 4. 5.
Current (the “As-Is”) Candidate (the desired system “To-Be”) Break “To-Be” into “chunks” or releases and prioritize Transition Plan(s) from current “As-Is” to the “To-Be” Charter, Tactical Planning, Project Planning, Schedule
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 6
The “As-Is” and “To-Be”
2
To-Be
Chunking & Prioritizing Releases
1 As-Is
Product Released
3 Transition Plan
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 7
What We’re Talking about Between
the “As-Is” and the “To-Be” is the equivalent to:
Blueprints (and just like blueprints they)
• Show components of your system • Show the relationships between them as to • Layout and who is involved in doing what • Creates “Institutional Knowledge” • Provides a tool and cornerstone for Change • Involves getting “buy-in” from stakeholders
So . . .
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 8
Why Do We Need Both an “As-Is” & A “To-Be” Model?
2
To-Be
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
To clearly communicate a solid approach and business benefits to secure Executive Sponsorship To Establish a Point of Reference, to Establish Where We Are ! To avoid missed steps that could jeopardize project success To manage the impact of change to organizations, people and processes Provide thorough and effective Transition Planning from the “As-Is” to the “To-Be” Package the changes into chunks or releases To sequence or prioritize releases
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 9
Models are . . .
Used to investigate possible improvements in the real “system” (business processes and the included components which make up a process) Also used to discover the effect of different policies on that system. Models help us to understand the behavior generated by the various components of a system. In Management Science, models of various types are used to represent a system. The simplest type of model is probably a scale model. For example, scale models are used to plan the layout of warehouses, factories, offices, etc. However, these models are static, they cannot show how the various factors dynamically interact, and they are not very flexible not adaptable. When you consider a model in your organization . . .
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 10
May '01
2
To-Be
Analysis Involves Considering
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
Components affected including: Organization Process People Management Controls Technology Facilities Products, Services External Agents Note that this applies to both your “As-Is” & “To-Be”
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 11
May '01
2
Process Centering Versus Process Redesign
To-Be
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
Process Centered is: Horizontal orientation, focused on end-to-end, cross-functional activities Challenging the underlying assumptions about the way we conduct business Smooth integration of processes across the org Creating an environment to support and reinforce process behavior
• • • • • •
May '01
BPR Vertical orientation, discrete functional areas
• Generate (sales), process (customer service), fulfill (production), distribute (logistics), bill (accounting), and post (finance)
alignment of strategy culture performance measures organizational design skills systems
Operate as a fragmented, unrelated set of activities Often with conflicting incentives, hand-offs, rework, errors and delays Believing that technology is the greatest investment and answer when in actuality the greater investment comes with making changes and creating new ways of working
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 12
Breaking From The Equilibrium From Traditional to BPR
Process 1
Dept A Dept B Dept C
Process 2 Process 3
Traditional - Stovepipe
Process / BPR Centric
In most businesses today, an event like obtaining a business license goes through a series of vertically organized departments. As a result, organizations may have a highly fragmented view of: 1) customers and 2) end-to-end business. May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy
Page 13
From BPR to Capability-Driven
Process 1 Process 2 Process 3 Capability 3 Process / BPR Centric
Focuses solely on Process without much consideration for other value-add capabilities
May '01
Capability 1 Capability 2
Capability-Driven
Focuses beyond Process to that of Enterprise-wide, value-added opportunities (looks for leveraging)
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 14
From Capability-Driven to Alliance-Based
Capability 2
Capability 1 Capability 2 Capability 3 Capability-Driven
Capability 1
Capability 3
Alliance-Based
Focused on newly forged Alliances and Partnerships for Enterprise-wide solutions, capabilities and Process Handoffs
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 15
Process Maturity Model
Capability 2
Process 1 Process 2 Process 3
Traditional Stovepipe Process / BPR Centric
Capability 1 Capability 2
Capability 1 Capability 3
Capability 3
Process Centric Alliance-Based
Process Centering and Breaking from the Equilibrium is A Conscious Effort
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 16
2
To-Be
A “Best Practice” Profile --
Chunking & Prioritizing Releases
1
3
As-Is
Synopsis -- Start Fresh Start with a clear slate Approach - A project isn’t always what you may think it is. Often organizations approach with a project that deals only with the surface result of the real problem or opportunity.
Transition Plan Product Released
Synopsis -- Set Outrageous Goals Wider is better. Approach - Assume the project’s reach is not limited to one department. Case a wide net and bring in players with different perspectives (people who don’t typically cross paths -- accounting with lawyers).
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 17
2
To-Be
Process Centering -What It Means
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
Think and manage in terms of cross-functional processes that were previously invisible Creating value as the process moves across the organization and end in a business outcome valued by the customer Assessing the gap between the current and desired business performance Redesigning the processes from the customer’s perspective Eliminating activities that don’t add value Creating a shared cross-functional process (Agency & Agencies) Designing process across enterprise boundaries Involving new partnerships and totally new process handoffs
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 18
2
To-Be
A “Best Practice” Profile --
Chunking & Prioritizing Releases
1
3
As-Is
Synopsis -- Incremental Advancement Consider replacing your current paper (license, permit, form) interface with an on-line (internal) interface.
Transition Plan Product Released
Benefits It’s simple Manages risk Allows demonstrating the proof-of-concept in a well controlled, internal environment Processes are untouched, just the user-interface is modified The scope of the project can be expanded to include easily managed process changes. With experiences gained, the program can move on to engineering processes that cross agency boundaries.
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 19
2
To-Be
A “Best Practice” Profile --
Chunking & Prioritizing Releases
1
3
Product Synopsis -- Steps to a new “To-Be” Released Envision what could be in a perfect world. Then, assess against the real world or current “As-Is.” This gap analysis is used to reach the desired state. Approach How can we add compelling value to our current and future customers? To our staff? How would we design it if we’re just starting a business, a digital business? Think of E-Commerce space as jointly owned: where can processes in your business transaction have new process handoffs? Where can participation with others occur (real-time, e-mail, FAX) or newly align with other internal systems?
As-Is
Transition Plan
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 21
2
To-Be
Chunking & Prioritizing Releases
“As-Is” Exercise
1
3
As-Is
Product Released
Transition Plan
Group discussion of Components (Events & Participants) relevant to your “As-Is” model What’s the value to:
Current “As-Is? To a Future “To-Be?
Reference: “As-Is Business Transformation” Word.doc (ATOM) 15 minutes
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 22
Worksession & Intermission
2
To-Be
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 23
Reconvene: “As-Is” Worksession
We left off at discussion of Components (Participants and Events) involved in your today’s “As-Is” situation. Asking: “How does each Participant add value to an Event Asking: “How does any Event add value to our end product / service?” A critical success factor is to apply this same activity and do it at a detailed level with your desired “To-Be” architecture
What’s It Mean To You? This will result in your Future Set of requirements
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 24
Transition Planning Best Practices
2
To-Be
Chunking & Prioritizing Releases
1 As-Is
Product Released
May '01
3 Transition Plan
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 25
A Transition Plan Involves . . .
Categorizing
TODAY’s OPERATIONS Today
• Maintaining the equilibrium • Manual processes, manual forms • Tweaking Business Plans • Variable processes & tools • Limited hours of service
Changes
NEW OPERATIONS Future
• Common and integrated system, tools • Extended Help Desk needed • Remake the Department • Use E-Form, E-License to create, innovate & transform business • Figure out how to exploit technology to boost % customer satisfaction
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 26
• __% customer satisfaction
May '01
The Next Slide Identifies What to Pay Attention to In Categorizing Your Changes
There are always opportunities to drill down to lower levels Note the importance to identify the differences between the “As-Is” and the “To-Be” Describe the changes required to evolve you current “As-Is” to the targeted “To-Be” Categorize the changes by the components affected (by resource, by software, procedures etc.)
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 27
Categorize the Changes
Current State
A S
I S
T O B E
Desired State
Type name here Type title here
Type name here Type title here
Type name here Type title here
Type name here Type title here
Organization
Process
Products
People
Controls
Facilities
Technology
– Identify the differences between the “As Is‟ and „To Be‟ – Describe in terms of the changes required to evolve the current to the target – Categorize the changes by the organizational component affected.
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 28
2
To-Be
Chunking & Prioritizing Releases
Transition Plan Exercise
1
3
As-Is
Product Released
Transition Plan
Separate into your teams Brainstorm specific changes between your “As-Is” to your “To-Be” for your project Ready to report your findings 15 minutes
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 29
Reconvene Transition Plan Worksession
You just went through an exercise on identifying changes between your “As-Is” and your desired “To-Be” Had you identified:
New staff skills or new staff required? Help Desk requirements (7x24x360)? New Training requirements? Changed roles of existing staff? New interfaces between your new application and a database, middleware, datawarehouse? New procedures or policies required?
The next foil provides a reminder to . . .
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 30
Balance Degree and Pace of Change
Need to Change
“To- Be” Process
Cost
Change Success Triangle Org. Health
Benefit
Performance Improvement
What results must you attain first? What is the timeframe for the attainment of the results? What are the dependencies between the work? How much change are you prepared to accept?
Impact on employees/business
Impact on suppliers/customers
Services Delivery
“Need to balance desired outcomes against organizational cost (dollar, org health and impact to existing work) and resulting benefit to customer”
May '01
How many resources are you prepared to make available? Which business specialists are you prepared to make available? How much risk are you prepared to consider?
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 31
Transition Planning Best Practices
Checklist:
Plan transition based on delivery of “chunks” of “To-Be” process which deliver organizational benefit Take Integrated Implementation approach (process, controls, people, technology, etc.) Assess trade-offs between Benefits, Costs and Risks along with Timing Develop individual project proposals for incremental releases Invest in transition monitoring mechanisms up-front (validation, feedback, transition team) Know change goals, change agents and change sponsors Communicate change Ensure proper hand-off between planning and execution Conduct multiple iterations to achieve desired scope and to unearth hidden requirements Foster innovation with an iterative process
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 32
2
To-Be
A “Best Practice” Profile --
Chunking & Prioritizing Releases
1
3
As-Is
Synopsis -It’s not enough to just do a Transition Plan. You will need to communicate it Early Often and Consistent
Transition Plan Product Released
At the: 1) Executive Level -- 2) Management Level -- 3) Staff Level (What’s it mean to them? What’s New, Changed, Going Away?)
Benefits Proactive Mitigates impacts and risks Facilitates acceptance and buy-in
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 33
Dynamic & Iterative Approach
2
To-Be
Chunking & Prioritizing Releases
1 As-Is
Product Released
3 Transition Plan
Outcomes?
Feature Set of Requirements
Iterations
Project Planning
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 34
Up To Now We’ve Been Through . . .
A Dynamic and Iterative Approach Going over the framework of Transition Planning A Transition Plan provides: Feature set of Requirements Iterations Project Planning And, also sequa’s to . . .
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 35
(. . . From Transition Plan to . . .) Project Plans to . . . Developed Releases
New To Be
R3 As Is R2 Release Plans Old To Be
R1
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 36
Considerations
You’ll need to take a look at:
Impacts to current application plans Possibly aligning your changes into releases Suspending redundant activities within the Agency, Dept. Configuration Management and Change Control Management Create / update Release Plans Communicate plans to Stakeholders up front
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 37
. . . From Transition Plan to Project Plans
Project # Project Name / Description Sponsor
Transition Plan Staging & “Chunks”
Project purpose & objectives
Project Plan
Project products Project # Project Name / Description Sponsor
Timeline
Project purpose & objectives
Resources
Activities
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
FTE by Skill Type
Project Plan
Project products Project # Project Name / Description Sponsor
Project purpose & objectives
Project Costs(ballpark range) Timeline Item Yr 1 $
Project Benefits (ballpark range)
Where (MCD) Activities Yr 1
1
2
3
4
5
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Project Plan
FTE by Skill Type
Resources
Yr 2
Yr 2
Project products
Yr 3
Yr 3
Performance Measures Complexity H/M/L Timeline Resources
Project Costs(ballpark range) Activities Item Yr 1 $
Project Benefits (ballpark range) Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Where (MCD) Yr 1 1 2 3 4 5
FTE by Skill Type
Yr 2
Yr 2
Yr 3
Yr 3
Performance Measures Project Costs(ballpark range) Complexity H/M/L Project Benefits (ballpark range)
Item Yr 1
$
Where (MCD) Yr 1
1
2
3
4
5
We included a list of Critical Success Factors and typical Issues Experienced on the next few foils -May '01
Yr 2
Yr 2
Yr 3
Yr 3
Performance Measures Complexity H/M/L
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 38
2
To-Be
A “Best Practice” Profile -Synopsis Remember to pay attention to Impact to current application plans and resources Aligning your changes into releases Suspending redundant activities Configuration Management Change Control Management Creating and updating Release Plans Communicating plans to stakeholders up front
Chunking & Prioritizing Releases
1
3
As-Is
Product Released
Transition Plan
Benefits Risk Mitigation
May '01
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 39
2
To-Be
Chunking & Prioritizing Releases
Critical Success Factors
1
3
As-Is
Product Released
Transition Plan
Analysis balanced against “analysis paralysis” Having a dynamic, iterative process versus a static, one-time approach Prepare and coach ahead of time for change Confirm objectives and expected outcomes with Executive Sponsors and “customers” Having the right “Content Experts” involved at each stage Executive Sponsorship with both Business & Technical Developing Impacts to the Organization and Risk assessments for given solutions and changes Developing a Transition Plan and preparing for change
Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 40
May '01
Issues Experienced
Not having the right players involved from the get go Making decisions based on gut-feel instead of profound knowledge based on “As-Is” to the “To-Be” architecture Little or no planning for resistance to change Scope creep or taking on “world hunger” (failing to stage initiatives) Little or non-existent Executive Sponsorship Having Business but no Technical Sponsorship (or visa versa) Too optimistic timeframes (failing to consider new KSA’s or competition of limited resources) Simply automating a manual process without considering benefits, customer experience, ROI, etc. Failing to apply known proven technology solutions to business problems Applying technology without knowing what the business issue is Failure to consistently communicate and market
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 41
Recap & Implications
Our approach covered today suggests: . . . Each stage of Transforming from the “As-Is” to “ToBe” has a pallet of potential tools and deliverables . . . Adapting to what we need to do to be successful . . .Capturing and reviewing business transformations . . . New adapting of technology -- technology moving very rapidly -- valuation of initiatives changes accordingly . . .What is a solution today may not prove to be viable tomorrow due to changing technologies or priorities -there’s a need then for a way in which to continually monitor, develop and adapt to change
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 42
For More Information . . .
Contact
John Specht -- (360) 902-2881 johns@dis.wa.gov
WASHINGTON STATE DIGITAL GOVERNMENT APPLICATIONS
A
cademy
Department of Information Services
May '01 Author / Focal: John Specht, (360) 902-2881 -- Digital Government Applications Academy Page 43