pmi presentation2
Post on 21-Jul-2015
188 Views
Preview:
TRANSCRIPT
Project Planning for System Migrations
Vincent Goldsmith, PMP, CSM
Agenda
Introduction
Migration Goals
Drivers
Portfolio Analysis
Requirement Recovery
Business Architecture
Target Architecture
System Design
Migration Paths
Implementation
Risk Mitigation
Stakeholder Buy-in
Conclusion
Introduction
• 25 years project management experience
• 15 years in IT
• Senior Project Manager with GDIT
• Currently assigned to a CMS Pay-for-
Performance Healthcare Project
(representative current and past clients and
associations shown)
PMBOK Alignment
Initiating Planning ExecutingMonitoring
and Controlling
Closing
Integration
Scope
Time
Cost
Quality
Human Resource
Communications
Risk
Procurement
Stakeholder
What is System Migration?
It is the transferring of IT resources to a newer hardware infrastructure or software platform for the purpose of keeping up with current technologies and/or to gain better business value in the long run.
Why This Is Important
• A lot of IT development is improving an existing system, usually resulting in the adoption of new software or hardware technologies (e.g. migration).
• Examples of IT Migrations:– Cloud Migrations (SaaS, IaaS, PaaS, etc.)
– Service Oriented Architecture (SOA)
– Open Source to Custom Code (or back again)
– Operating Systems
– Data migrations
Why This Is Important• IT Migrations are complicated because of the
following:– Differences in source and target architectures– Known and unknown dependencies– Undocumented requirements– Impact to business operations– Applications are rarely portable across different
technologies– Developers and/or users are not trained in new
technologies– Non-routine processes and procedures
(reengineering doesn’t happen every day)
Project planning is important because IT projects are hard enough without these complications….
70% of organizations have suffered at least one project failure in the prior 12 months – KPMG (2010)
60% of projects failed to meet schedule, budget and quality goals – IBM (2008)
37% of business process change projects fail to deliver benefits –Logica (2008)
38% of data migration projects fail – Computer Business Review (2013)
GAO: $10 billion worth of current federal IT contracts could fail –Washington Post (2014)
17 percent of large IT projects go so badly that they can threaten the very existence of the company – McKinsey & Company (2012)
Why This Is ImportantFrom people who have studied this stuff…
Excuses – Excuses - Excuses
• “If managing technology pays your mortgage, you usually explain away those failures by pointing to your gray world: gray requirements, gray resources, gray planning, gray risks. The only vibrant color in your life is the brilliant hue of overly optimistic project scheduling.”
– “Why Tech Projects Fails, 5 Unspoken Reasons”, Information Week, April 2013
We Do It To Ourselves
• The biggest barriers to success are people factors IBM (2008)
– Changing mindsets and attitudes – 58%.
– Corporate culture – 49%.
– Lack of senior management support – 32%
– Underestimation of complexity listed as a factor in 35% of projects
• “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that 75% of project participants lack confidence that their projects will succeed from the start of the project (Geneca 2011).
We Can Do Better
Planning Goals
Goals for a Migration Project
• Successful migration of applications or data to new software and hardware technologies.
• Least amount of business disruption or risk to business operations.
• Predictable timeline for when functionality will be migrated.
• Adoption and use of migrated products and services.
Outputs of Migration Planning
Scope• What applications are in scope for migration• System boundaries
Schedule• Timeline for implementation• Date of completion
Project Management Plan• Updates to Quality Management Plan, Risk
Management Plan, Communications Plan, etc.
Scope, Schedule and Project Management Plan
MIG
RA
TIO
N C
OM
PLE
TE
Migration Planning Framework
Target Architecture
Portfolio Analysis
Requirement Recovery
Business Architecture
Implementation
Migration Path
Establish Baseline
RET
AIN
REP
LAC
E
REF
AC
TOR
RET
IRE
REV
ISE
REB
UIL
D
REH
OST
System Design
Identify Drivers
Road Map
STAKEHOLDER BUY-IN
RISK MITIGATION
QUALITY ASSURANCE
Business & Technical Drivers
78% of respondents reported that the “Business is usually, or always, out of sync with project requirements”
– Geneca (2011)
Main Drivers for Migration
• The current system no longer performs as expected or needed.
• A faster or better performing technology becomes available.
• The old system becomes deprecated and support is difficult or no longer available for it.
• The company is taking a change in direction.
• Cost of development or support.
Other Considerations
• Migration is sometimes driven by IT management and not business management, but that doesn’t mean the business needs shouldn’t be addressed.
• Analyzing drivers may uncover business reasons that will end-up driving your strategy or schedule:– security concerns, capacity or performance concerns, data
quality concerns, compliance reasons, new business initiatives that can’t be accomplished in the legacy architecture
• Reasons to migrate can be both business or technical in nature.
Perceived Benefits
Perceived Benefit (example) Business Technical
Rapid Time to Market X X
Deliver New Capabilities X X
Modernize Applications X
Accommodate Scalability X
Free-up Data Space X
Operational Efficiencies X
Provide Access to More Users X
Improve Performance X X
Better Data X
Improve Security X X
Leverage existing investments X X
Other Considerations
• Fully understanding the business drivers allows you do the following:
– Establish a timeline acceptable to the business that accommodates their schedules and deadlines
– Prioritize functionality or applications that need to be migrated (scope)
– Form a plan for the migration that minimizes business risk while maximizing business value
Drivers are not Static
• They need to be revisited throughout the migration process to determine if they are still relevant or if benefits are being realized.
• All the analysis and decisions that follow should be assessed as compared to the drivers.
Legacy System Analysis
Legacy Systems
They represent:
• Huge Investment
• Baseline for Future Functionality
Portfolio Analysis
All applications are reviewed by representatives of the business and technical teams and judged according to the following:
• Functional Value• Technical Value
Qualitative judgments are given quantitative values and a weighted score is calculated for each application.
Applications are reviewed and a decision is made on the prospects of the applications.
Return-on-Investment (ROI) should be calculated and evaluated against the cost of migration.
Functional Analysis
Evaluate Legacy Systems to see if they meet the needs of the business (examples):
• Business Need/Functionality (don’t migrate what you can eliminate)
• Business efficiency or workflow automation
• Performance
• Usability
• Strategic Fit
Technical Analysis
Evaluate Legacy Systems to see if they meet the needs of the people supporting the technology (examples):
• Technical Maturity• Technical Debt• Data Dependencies• Architecture• Portability• Reliability• Interoperability• Cost of development and support
Legacy Data Issues
Evaluate Legacy Systems for data quality issues (examples):
• Bad data in legacy system
• Duplicate data in legacy system
• Unknown or unenforced archiving policies
• Upstream data dependencies or third-party data needs
Possible Decision Outcomes
Decision Definition
Retain No changes made to application
Replace Discard existing application and replace with COTS
Refactor Making application or configuration changes to upgradeapplication without changing functionality
Retire The functionality of the application is no longer needed by the business.
Revise Extending existing legacy application functionality to accommodate business needs
Rebuild Completely rebuilding the application with a brand new architecture
Rehost Deploy applications to a different hardware environment and/or changing the infrastructure
Legacy Portfolio Analysis
Application Portfolio Decision Analysis
FUN
CTI
ON
AL
VA
LUE
TECHNICAL VALUE
RETAIN
REBUILD
REFACTOR
RETIREREVISE
REPLACE
REHOST
Requirement Recovery
Undocumented Requirements
• Incomplete requirement documentation is an issue in legacy systems migrations.
• Unclear requirements are one of the contributing factors to IT project failures, so it is important to document all of the business requirements.
• Business requirements should be further broken down into functional and non-functional requirements and/or technical and functional specifications.
• Legacy requirements may change depending on the outcome of the Portfolio Analysis.
Sources of Requirements
• Re-elicit requirements
• Reverse engineer existing applications by reviewing code
• Review Business Architecture and BPMNs
• Review training materials, user guides, release notes for info
• Review test cases if available
• Analyze inputs and outputs
Requirement Management Still Applies
• Have a requirements management plan
• Requirements should describe functionality and outcomes, not technical implementation
• Requirements and associated documents should be kept under change management
• Maintain clear traceability of requirements
• Strive for enterprise-wide requirements as opposed to application-specific requirements
More Info
There is an abundance of scholarly papers on how to elicit, derive, and represent user requirements, including:
• Semantic Analysis
• Analyst Constrained Language (ACL)
• Norm Analysis
• Etc.
Business Architecture
Business Architecture
• Business architecture defines how the enterprise needs to operate in order to achieve business objectives.
• It is the first architecture activity that takes place.• The existing business architecture is usually
defined within the legacy system.• It should be verified, analyzed, and updated as
necessary.• Business processes not being brought forward
into the new system should be removed.
TOGAF Business Architecture Steps(The Open Group Architecture Framework)
1. Select Reference Models, Viewpoints, and Tools
2. Develop Baseline Business Architecture Description
3. Develop Target Business Architecture Description
4. Perform Gap Analysis5. Define Candidate Roadmap
Components6. Resolve Impacts Across the
Architecture Landscape7. Conduct Formal Stakeholder Review8. Finalize the Business Architecture9. Create Architecture Definition
Document
Other Considerations
• Value engineering and possible cost-cutting should be made part of the process.
• Validate and redefine business rules.
• Identify cross-process dependencies.
• Identify inputs & outputs of the system boundaries within the business architecture.
• Adhere to standards and governance.
Outputs of Defining the Business Architecture
The following diagrams should be considered as possible outputs of the Business Architecture process (more from Togaf-modeling.org):• Business Footprint diagram• Business Service/Information diagram• Functional Decomposition diagram• Goal/Objective/Service diagram• Use-case diagram• Organization Decomposition diagram• Process Flow diagram• Events diagram
Business Footprint DiagramProvides a clear traceability between a technical component and the business goal that it satisfies, while also demonstrating ownership of the services identified.
Source: togaf-modeling.org
Functional Decomposition Diagram
Shows on a single page the capabilities of an organization that are relevant to the consideration of an architecture.
Source: togaf-modeling.org
TargetArchitecture
Target Architecture
• It serves as the overall framework for the solution architecture.
• It is the formal documentation of the desired future vision -defining and validating future requirements and the optimization of opportunities.
Additionally…• It is the high level plan for the relationship between
business and application systems.• It defines the relationship between business and
information.• It describes the relationship between business and
technologies.
Describing the Target Architecture
• Data Standards:– Coding and values for data– Structures and formats for data– Ownership of data– Restrictions on access
• Applications Standards:– Standard/shared applications and services that support specific
business functions– Application communication, interfaces and interoperation– Access, presentation, and style
• Technology Standards;– Hardware product standards– Software product standards– Software development standards
Creating the Target Architecture(example process)
Source: A Practical Guide to Federal Enterprise Architecture
System Design
System Design
System design is the complete set of documents necessary to implement the applications.
Documents can include:
• Data Models
• Interface Control Documents
• Configuration Documents
• System Implementation Plans
System Design• Trace technical solutions at the component level to
requirements.
• Design the system so it can be implemented iteratively to accommodate your migration path.
• There might not be a one-to-one relationship between new components and legacy components.
• Review performance and security issues that may arise between new and existing applications and architectures.
• Enforce standards and change control with new system designs.
System Design
• Design for common shared elements when possible.
• Have a preferred mechanism for common capabilities (build these first):– Authorization
– Communication/email
– Synchronization
– Error handling
– Event logging, etc.
Design for Incremental Migration
• Changes in protocols or database formats should accommodate existing data, applications and devices in order to be backward compatible.
• Wrapping existing applications with new APIs can facilitate incremental migration while allowing for backward compatibility.
Migration Paths
Transition Architecture: “In Flight”
• When choosing a migration path there are three basic strategies:– a completely new implementation.– a radical “all or nothing” change (i.e., switch on, switch
off).– a phased approach to introduce new capabilities with
parallel legacy and migration systems running simultaneously.
• Of these, a phased approach is the lowest risk method and allows for easy and quick wins to prove the migration will work.
“As Is” System
UI
Business Logic
Data
UI
Business Logic
Data
UI
Business Logic
Data
UI
Business Logic
Data
UI Domain
BusinessDomain(s)
Data
“To Be” System
UI
Business Logic
Data
Business Logic
Business Logic
Business Logic
UI Domain
BusinessDomain(s)
Data Cloud Big Data Appliance
Iterative System“In Flight” Option: Migrate by App
UI
Business Logic
Data
UI
Business Logic
Data
UI
Business Logic
UI
Business Logic
Data
UI Domain
BusinessDomain(s)
Data Cloud
Iterative System“In Flight” Option: Migrate UI
Business Logic
Data
Business Logic
Data
Business Logic
Data
Business Logic
Data
UI Domain
BusinessDomain(s)
Data
UI
BusinessDomain(s)
Iterative System“In Flight” Option: Migrate by Domain
UI
Business Logic
Data
UI
Business Logic
Data
UI
Business Logic
Data
UI
Business Logic
Data
UI Domain
Data
Iterative System“In Flight” Option: Data Migration
UI
Business Logic
Data
UI
Business Logic
UI
Business Logic
UI
Business Logic
UI Domain
BusinessDomain(s)
Data Cloud Big Data Appliance
“To Be” System
UI
Business Logic
Data
Business Logic
Business Logic
Business Logic
UI Domain
BusinessDomain(s)
Data Cloud Big Data Appliance
Implementation
Implementation
• Identify enterprise architecture and implementation priorities for development teams.
• Identify deployment issues and determine corrective actions.
• Pay attention to the scope of migration efforts and iterative development schedule.
• Extract, clean, transform and de-duplicate the data.
• If necessary prepare scripts for data, server or database migrations.
Implementation Teams
• Current technical and or business SMEs have detailed knowledge critical to not just the ongoing O&M of the system, but they are also critical to the migration effort.
• New technical SMEs may be needed for the development or implementation of new systems.
• Implementation Teams made up of a mix of current and new technical and business resources maximize potential for success.
Implementation Team Example
Application UI Developer Service Developer
Database Developer
FunctionalSME
Component 1 LegacyDeveloper
MigrationDeveloper
Legacy Developer
Legacy SME
Component 2 Migration Developer
Legacy Developer
Migration Developer
Legacy SME
Component 3 Migration Developer
Migration Developer
MigrationDeveloper
Legacy SME
Training
• Training for the existing technical staff is needed so that new habits and design practices will be used when working with the new architecture.
Risk Mitigation
Risk Mitigation
• Parallel environments (ongoing legacy operations and migration implementation) should be leveraged.
• Establish and maintain configuration management control of the legacy system even while migrating.
• There should be a separate and distinct reengineering process that doesn’t interfere with the ongoing operations of the legacy system.
• When outside services are needed, carefully define and monitor their roles.
Risk Mitigation
• Restrict migrations to off-hours when usage is low and won't interfere with your ongoing operations.
• Maintain a clear audit trail of all data migration activitity (who, what and when).
• Validate and test the data-migration process.
• Don’t plan to go live in one big upload at the end – work incrementally.
• Training – training – training.
D Quality
Quality Assurance
• Parallel environments will allow you to compare migrated test results to baseline.
• UAT testing should be done on migrated components (training will be needed).
• Maintain traceability of test cases back to requirements.
Data Quality Assurance
• Back-end testing is critical when migrating incrementally because you want to be able to test components as they are developed.
• Testing of the migration run (ETL) should be done to make sure all three stages are functioning correctly.
• Test the migrated data to ensure it's accurate and in the expected format.
• If scripts are being used to migrate data, servers, etc. – the scripts should be tested thoroughly as well.
User and Developer Buy-in
Stakeholder Buy-In
Stakeholder Buy-In
• “75% of project participants lack confidence that their projects will succeed, even from the start of the project”
Stakeholder Buy-In
• Development team and User buy-in is critical to success (many IT implementations fail due to insufficient adoption of new technology).
• Provide adequate training and communication in both the technical content and the reason for the change.
Stakeholder Buy-In
• Get input from legacy SMEs, Technical Staff and Usersvery early in the process – and ask them for their opinions.
• Create a team-oriented reengineering plan.• Have a subset of users who are involved throughout
the migration process.• Project and team onboarding should include an
overview of the migration strategy.• Demonstrate products early and often.• Overcommunicate progress and success.• Celebrate wins early and often.
Sponsorship
• The migration project should have a senior manager sponsor.
• Management needs to be committed for the long haul.
• Management edicts should not override technical realities.
Conclusion
Review• Work early and often to achieve and maintain
stakeholder buy-in (users and technical staff) through training and communication.
• Continue to revisit business and technical drivers to make sure you’re delivering value.
• Develop a comprehensive strategy with achievable and measurable milestones for the project.
• Deliver incremental migration.
Scope, Schedule and Project Management Plan
MIG
RA
TIO
N C
OM
PLE
TE
Migration Planning Framework
Target Architecture
Portfolio Analysis
Requirement Recovery
Business Architecture
Implementation
Migration Path
Establish Baseline
RET
AIN
REP
LAC
E
REF
AC
TOR
RET
IRE
REV
ISE
REB
UIL
D
REH
OST
System Design
Identify Drivers
Road Map
STAKEHOLDER BUY-IN
RISK MITIGATION
QUALITY ASSURANCE
And Remember
…We Can Do Better
More Information• Five Options for Migrating Applications to the Cloud: Rehost, Refactor,
Revise, Rebuild or Replace (.pdf) – Gartner
• A Practical Guide to Federal Enterprise Architecture (GAO)
• The Object Management Group (OMG)
• The Open Group Architectural Framework (TOGAF)
• Information Technology Infrastructure Library (ITIL)
• Software Engineering Institute (SEI)
• Project Management Institute (PMI)
• AgileModeling.com (for modeling and documentation)
• Togaf-modeling.org (for modeling and documentation)
The End
Questions
linkedin.com/in/VincentGoldsmith
Vincent Goldsmith
VinnyGoldsmith@gmail.com
301-452-7906
top related