A Risk Management-Driven  Deployment Framework for Project  Ownership/Accountability                                      ...
Purpose of this presentationEngage Project Managers (PM) who are interested in enhancing their skillset around managing or...
AgendaIntroductions   [~ 5mins]Some context     [~15mins]  Enabling and sustaining change  Stakeholder managementLeveragin...
“Managing” changeWhy is it important?                           What is it?  2008 McKinsey worldwide survey of 3,199      ...
Enabling & Sustaining Change                                                                                        All ab...
Enabling & Sustaining Change                                                               Main focus today               ...
Stakeholder Management is fundamentalStakeholder advocacyStakeholders are all around:   Internal (e.g., corporate, busines...
Stakeholder engagement levels                                                                                         stak...
Main components of approachPreliminary                       Risk Assessment                  Deployment planning         ...
(Simple) ExampleRisk Assessment • Identify stakeholder groups within BUs (homogeneous groups of users)• Identify and selec...
Risk assessmentStandard template used to identify and document risks & issues through joint collaboration between the busi...
Scope of Risk Assessment [example]Data collected                                                          Risk levels  Dem...
Deployment planningBegin implementing mitigationsSchedule and complete testingSchedule and complete training customized to...
Deployment Final deployment schedule determined based :   - level of risk associated with the deployment to a particular g...
Pull & Push [example]             •Training/demos take place and  work aides distributed             •Applications made av...
Summary of benefitsBusiness plays a key role in the identification and mitigation of business and user‐related risksDeploy...
Your thoughts & Questions?
About the presenter   Allen Stines, PhD   e-mail: allenstines@gmail.com   LinkedIn: www.linkedin.com/in/allenstines   Blog...
Upcoming SlideShare
Loading in …5

A Risk Management-Driven Deployment Framework for Project Ownership/Accountability - by Allen Stines, PhD-- Project Management Institute (PMI) LEAD Community of Practice (LEAD CoP) webinar presentation (Sep 7, 2011)


Published on

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

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Risk Management-Driven Deployment Framework for Project Ownership/Accountability - by Allen Stines, PhD-- Project Management Institute (PMI) LEAD Community of Practice (LEAD CoP) webinar presentation (Sep 7, 2011)

  1. 1. A Risk Management-Driven Deployment Framework for Project Ownership/Accountability By Allen Stines, PhDPresented Sept 8, 2011Webinar - Project Management Institute (PMI) LEAD Community of Practice (CoP) Copyright © 2011 Allen Stines
  2. 2. Purpose of this presentationEngage Project Managers (PM) who are interested in enhancing their skillset around managing organizational and operational change (or simplyavoiding some of its pitfalls)Promote deployment approaches that are IMPLEMENTED WITH thebusiness as opposed being IMPOSED ON the businessShare a deployment framework with risk management at its core. One thatleverages stakeholders to minimize and manage deployment-related risksthrough 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 drillsContinue the conversation and engage PMs who are interested in sharingbest practices: what works and what to avoid
  3. 3. AgendaIntroductions [~ 5mins]Some context [~15mins] Enabling and sustaining change Stakeholder managementLeveraging stakeholders to help manage deploymentrisks [~35 mins] Preliminary stakeholder stratification Risk assessment (organizational/operational) Deployment planning (organizational/operational) DeploymentYour thoughts, comments, & questions [~ 5mins]
  4. 4. “Managing” changeWhy 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. 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. 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. 7. Stakeholder Management is fundamentalStakeholder advocacyStakeholders are all around: Internal (e.g., corporate, business unit, functional areas, …) External (e.g., customers, suppliers, regulators, …) Project teamsStakeholder 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 effectiveManaging change impacts 2 degrees remote Understanding the impacts not just on stakeholders but on stakeholders’ stakeholders
  8. 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. 9. Main components of approachPreliminary  Risk Assessment Deployment planning  Deploymentstakeholder  (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. 10. (Simple) ExampleRisk 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 stratificationDeployment 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 planDeployment  (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. 11. Risk assessmentStandard template used to identify and document risks & issues through joint collaboration between the business/functional area and its IT repDeployment risk review session is conducted with business, IT, and project teamRecommendations on risk mitigation are generated jointly by the business and the project teamStakeholder stratification is revisited and adjusted based on risk assessmentSelection of mitigations/solutions is a joint effort between business leaders and project team 1
  12. 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 1Recommendations 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. 13. Deployment planningBegin implementing mitigationsSchedule and complete testingSchedule and complete training customized to local needsFinalize “change management” activities to support deploymentIdentify deployment Critical Success Factors (CSFs)Devise benefits realization frameworkAlign stakeholder expectationsSocialize the changes and vet through leadership - vet at appropriate level, if a lot of changes, potentially institute mid‐point reviewsConduct readiness status of testing and mitigations - If “Go”, prepare for rollout - If “No‐go” establish timeline for remediation and future migration 13
  14. 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 issuescan be identified mitigated prior to deploying to high risk groups 2
  15. 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 iterationsDeployment 15
  16. 16. Summary of benefitsBusiness plays a key role in the identification and mitigation of business and user‐related risksDeployment  impacts are proactively identified and rollout is customized and adapted to fit operational/organizational needs and minimize disruptions to the businessDeployment 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. 17. Your thoughts & Questions?
  18. 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).