Leveraging stakeholder input to continually identify, assess, mitigate, and manage deployment risks while fostering buy-in, shared ownership and joint accountability

1. A Risk Management-Driven
Deployment Framework for Project
Ownership/Accountability
By Allen Stines, PhD
Presented Sept 8, 2011
Webinar - Project Management Institute (PMI) LEAD Community of Practice (CoP)
Copyright © 2011 Allen Stines

2. Purpose of this presentation
Engage Project Managers (PM) who are interested in enhancing their skill
set around managing organizational and operational change (or simply
avoiding some of its pitfalls)
Promote deployment approaches that are IMPLEMENTED WITH the
business as opposed being IMPOSED ON the business
Share a deployment framework with risk management at its core. One that
leverages stakeholders to minimize and manage deployment-related risks
through joint accountability and enables the following:
Co-ownership of outcome/Shared responsibility
Deployment that is highly customized to local needs
Early detection of potential issues
Less fire drills
Continue the conversation and engage PMs who are interested in sharing
best practices: what works and what to avoid

3. Agenda
Introductions [~ 5mins]
Some context [~15mins]
Enabling and sustaining change
Stakeholder management
Leveraging stakeholders to help manage deployment
risks [~35 mins]
Preliminary stakeholder stratification
Risk assessment (organizational/operational)
Deployment planning (organizational/operational)
Deployment
Your thoughts, comments, & questions [~ 5mins]

4. “Managing” change
Why is it important? What is it?
2008 McKinsey worldwide survey of 3,199 First, the term is an oxymoron
executives reported that only about 1 in 3
initiatives were successful The art and science of managing
stakeholders with divergent interests while
IBM’s 2008 “Making Change Work” attempting to forecast the unknown and
surveyed 1,500 practitioners worldwide address complex organizational and
about 60 percent of the projects FAILED to operational issues that arise in complex
fully meet their objectives. organizational systems.
2009 article in McKinsey Quarterly noted Involves spending time with the impacted
that surveys conducted during the stakeholders, walking in their shoes,
previous 10 years yielded the same results understanding their concerns, putting in
that only about 30 percent of change- place the necessary support structure and
related initiatives were successful reassuring them that they will be equipped
to deal with the changes that are coming
Business transformations are not fully
successful not only because of a lack of In summary, it’s lots of dialoguing, lots of
change management activities but also brainstorming, and a whole lot of “pro-
because of poor change management active problem solving”
frameworks

5. Enabling & Sustaining Change
All about the stakeholders
Manage Plan Change Mgmt is an oxymoron
Management
Systemic approach
4 major workstreams
Coordinate
Scope creep is the norm
Manage the change process,
not attempt to control it
A good sensing network is key!
Sensing &
Monitoring
Mitigate Sense Stakeholder advocacy is key!
Willingness to question
Assess
Opportunities to improve the
effectiveness of deployment
Network of change agents
Equipping people to change
Sustainment
Enhancing buy-in/ownership
Sustain Anchor
Drive Align
Making sure the change sticks
Enable Transition
Enablement
Copyright © 2011 Allen Stines

6. Enabling & Sustaining Change
Main focus today
Sensing & monitoring activities
Enablement activities
Tricky to measure
Many “easy to measure” but worthless
metrics typically used
More perceived value in extinguishing
Sensing & Mitigate Sense fires then preventing them
Monitoring
If done well, bad things DON’T happen
Delayed gratification factor
Assess
Drive Align
Enable
Enablement
Copyright © 2011 Allen Stines

7. Stakeholder Management is fundamental
Stakeholder advocacy
Stakeholders are all around:
Internal (e.g., corporate, business unit, functional areas, …)
External (e.g., customers, suppliers, regulators, …)
Project teams
Stakeholder stratification can be difficult. One size never fits all
shouldn’t simply lump a functional area or operational area together
finding the right level of granularity can be tricky (e.g., some groups could be as large as 1,000
and others as small as 2)
as a rule of thumb, the more granular and customized, the better (conversely, the more
granular, the higher the overall level of effort)
A good rule of thumb is to apply the “platinum rule” instead of the
“golden rule”
The interaction must be 2-way to really be effective
Managing change impacts 2 degrees remote
Understanding the impacts not just on stakeholders but on stakeholders’ stakeholders

8. Stakeholder engagement levels stakeholders
High Full
Engagement
ACCOUNTABILITY
ACCEPTANCE
Commitment
Internalization
Awareness
Project team
Low
Initiation Transition
TIME
Levels
• Awareness: Individuals are knowledgeable of the goals of the initiative & its perceived impacts
• Internalization: Individuals understand the impacts (+/-) to their job and to their functional area. They
have begun to recognize the personal gaps that must be filled in order to operate in the new environment
• Commitment: Individuals are actively gaining the skills and knowledge they will need to operate in the
new environment
• Full Engagement: Individuals are actively working to further improve the desired future state so that it
better fits the needs of their functional areas or teams
The change strategy should focus on moving stakeholders up the
curve until they reach their respective expected level of engagement

9. Main components of approach
Preliminary Risk Assessment Deployment planning Deployment
stakeholder (risk‐based)
stratification
• Impact assessment • Risk assessment •Risk & issue mitigation • Pull
• Stakeholder stratification framework •Alignment • Push
• Change Agent Network • Risk assessment review •Enablement • Sustainment
• Realignment of
stakeholder stratification
9

10. (Simple) Example
Risk Assessment
• Identify stakeholder groups within BUs (homogeneous groups of users)
• Identify and select business and/or IT representatives for each stakeholder group
• Deployment BU/IT Reps (1) document all issues and risks to be mitigated and (2) identify constraints (e.g., blackouts dates)
• Risk/deployment review session
• Assign level
• Revisit stakeholder stratification
Deployment planning (based on assessment)
• Schedule and complete all testing, training
• Investigate and address all integration issues identified in assessment phase (if needed)
• Socialize and vet the changes with the stakeholders
• One week prior to the pull date*, reassess status of mitigations and testing (go/no‐go phase gate)
• If “go”, (1) communication goes out to users announcing new system will be made available in 1 week, and (2) info
provided to setup APM
• If “no‐go”, document and identify plan
Deployment (4 weeks or as negotiated with stakeholder group)
• Make application available for download
• Send notification e‐mail on pull day to all employees within business unit.
• Conduct training (based on need)
• Send weekly message with push reminder notices (Weeks 1 , 2 , 3)
• Identify all migration exceptions by week 3 (if needed)
• System is pushed 4 weeks after pull date (unless otherwise notified)
• Offer “clinic”
• Debrief/Lessons Learned review takes place within 2 weeks after push date
*Pull date: date when system is available for optional download by the user
Push date: date when system is automatically uploaded onto a user’s machine (if the user hadn’t already downloaded it) 10

11. Risk assessment
Standard template used to identify and document risks & issues through
joint collaboration between the business/functional area and its IT rep
Deployment risk review session is conducted with business, IT, and
project team
Recommendations on risk mitigation are generated jointly by the
business and the project team
Stakeholder stratification is revisited and adjusted based on risk
assessment
Selection of mitigations/solutions is a joint effort between business
leaders and project team
1

12. Scope of Risk Assessment [example]
Data collected Risk levels
Demographics of a particular group (e.g. Size,
average skill level, adoption “comfort”,…) • Business Critical
(e.g., financial, regulatory, safety impacts)
Business impacts (operational/organizational)
Level 3
Testing w/ level of effort
Identification of the level and mode of training
that will be required • Non‐critical Operational Impact
(e.g., impacts to non‐critical processes )
Identification of blackout periods
Level 2
Potential need for concurrent migrations
Exceptions
• Limited Impact
(e.g., impacts to users)
Level 1
Recommendations
Estimated # of weeks needed to mitigate all
identified issues and risks
Low risk deployments occur first, followed by
Assigned risk level medium risk, “unexpected” issues can be identified
mitigated prior to deploying to high risk groups
12

13. Deployment planning
Begin implementing mitigations
Schedule and complete testing
Schedule and complete training customized to local needs
Finalize “change management” activities to support deployment
Identify deployment Critical Success Factors (CSFs)
Devise benefits realization framework
Align stakeholder expectations
Socialize the changes and vet through leadership
- vet at appropriate level, if a lot of changes, potentially institute mid‐point reviews
Conduct readiness status of testing and mitigations
- If “Go”, prepare for rollout
- If “No‐go” establish timeline for remediation and future migration
13

14. Deployment
Final deployment schedule determined based :
- level of risk associated with the deployment to a particular group*
- level of effort needed to mitigate the risks identified
- Blackout periods
- Support criteria for risk level
Deployment stats and trends monitored by project team (e.g.,
“adoption rates”, issues, …)
Business monitors progress and provides updates at weekly meeting
Most communications are channeled through the business and
adapted to fit local culture
After action review conducted jointly by project team and integrated
into the next iteration
Complete transition activities
* Given that low risk deployments occur first, followed by medium risk deployments, unanticipated issues
can be identified mitigated prior to deploying to high risk groups
2

15. Pull & Push [example]
•Training/demos take place and work aides distributed
•Applications made available and user is notified
•Pull period scheduled for 4 weeks (or as negotiated with the business unit or group)
•Messages sent at the end of weeks 1, 2, 3 by the Rep (communicate push week)
•Deployment Rep monitors progress and provides updates at weekly meeting
•Deployment stats and trends monitored by project team
Pull •During pull period, continuously communicate process to be put on exception list (w/ business justification)
•At week 3, review exemption list
•If threshold is met, plan for push
•Applications pushed to all users except those on the exception list
Push
•Offer “clinic”
•Deployment Reps and project team conduct “after action review” of the deployment process
•Reps document and debrief other reps and project team
Post •Lessons learned are incorporated in the deployment process for upcoming iterations
Deployment
15

16. Summary of benefits
Business plays a key role in the identification and mitigation of
business and user‐related risks
Deployment impacts are proactively identified and rollout is
customized and adapted to fit operational/organizational needs
and minimize disruptions to the business
Deployment is modular change management activities are
customized to the needs and culture of a specific group of users
Shared ownership, buy‐in, and accountability
16

17. Your thoughts & Questions?

18. About the presenter
Allen Stines, PhD
e-mail: allenstines@gmail.com
LinkedIn: www.linkedin.com/in/allenstines
Blog: http://allenstines.blogspot.com
Allen Stines is an organizational effectiveness & strategic change architect who has designed, managed and
enabled business transformation in a wide range of functional areas including operations, IT, HR, finance,
supply chain, market management, and various technical areas. He has worked in a variety of industry
sectors such as energy, manufacturing, education, government, and health care.
Over the past decade Allen has led a broad range of initiatives aimed at transforming the way an
organization conducts business. He’s driven systemic change while aligning stakeholders across multiple
functional areas, designing and implementing strategies that enable the transformation of businesses by
mitigating organizational risks and strengthening the overall alignment of people and business processes to
support and execute strategy.
He also conducts research and is collaborating on a series of articles defining a risk‐based change
management framework. Allen has completed undergraduate degree programs in Business Operations (BS),
Applied Math & Statistics (BS), and graduate degree programs in Systems Management (MS), Educational
Computing (AGC), and Workforce & Organization Development (PhD).