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

By Allen Stines, PhD

Copyright © 2011 Allen Stines

Presented Sept 8, 2011Webinar - Project Management Institute (PMI) LEAD Community of Practice (CoP)

A Risk Management-Driven Deployment Framework for Project Ownership/Accountability

Purpose of this presentationEngage 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 responsibilityDeployment that is highly customized to local needsEarly detection of potential issuesLess fire drills

Continue the conversation and engage PMs who are interested in sharing best practices: what works and what to avoid

AgendaIntroductions [~ 5mins]

Some context [~15mins]

Enabling and sustaining changeStakeholder management

Leveraging stakeholders to help manage deployment risks [~35 mins]

Preliminary stakeholder stratificationRisk assessment (organizational/operational)Deployment planning (organizational/operational)Deployment

Your thoughts, comments, & questions [~ 5mins]

“Managing” changeWhy is it important? What is it?

2008 McKinsey worldwide survey of 3,199 executives reported that only about 1 in 3 initiatives were successful

IBM’s 2008 “Making Change Work” surveyed 1,500 practitioners worldwide about 60 percent of the projects FAILED to fully meet their objectives.

2009 article in McKinsey Quarterly noted that surveys conducted during the previous 10 years yielded the same results that only about 30 percent of change-related initiatives were successful

Business transformations are not fully successful not only because of a lack of change management activities but also because of poor change management frameworks

First, the term is an oxymoron

The art and science of managing stakeholders with divergent interests while attempting to forecast the unknown and address complex organizational and operational issues that arise in complex organizational systems.

Involves spending time with the impacted stakeholders, walking in their shoes, understanding their concerns, putting in place the necessary support structure and reassuring them that they will be equipped to deal with the changes that are coming

In summary, it’s lots of dialoguing, lots of brainstorming, and a whole lot of “pro-active problem solving”

Enabling & Sustaining ChangeAll about the stakeholdersChange Mgmt is an oxymoronSystemic approach4 major workstreamsScope creep is the normManage the change process, not attempt to control itA good sensing network is key!Stakeholder advocacy is key!Willingness to questionOpportunities to improve the effectiveness of deploymentNetwork of change agentsEquipping people to changeEnhancing buy-in/ownershipMaking sure the change sticks

Plan

Coordinate

Manage

Sense 

Assess 

Mitigate 

Align

Enable 

Drive  Anchor 

Transition 

Sustain

Management

Sensing & Monitoring

Enablement

Sustainment

Copyright © 2011 Allen Stines

Enabling & Sustaining ChangeMain focus today

Sensing & monitoring activitiesEnablement activities

Tricky to measureMany “easy to measure” but worthless metrics typically usedMore perceived value in extinguishing fires then preventing themIf done well, bad things DON’T happenDelayed gratification factor

Sense 

Assess 

Mitigate 

Align

Enable 

Drive  

Sensing & Monitoring

Enablement

Copyright © 2011 Allen Stines

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 allshouldn’t simply lump a functional area or operational area togetherfinding 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 remoteUnderstanding the impacts not just on stakeholders but on stakeholders’ stakeholders

Stakeholder engagement levels

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 thecurve until they reach their respective expected level of engagement

FullEngagement

T I M E

ACCEP

TAN

CE

High

Low

Awareness

Internalization

Commitment

Initiation Transition

ACCO

UN

TABIL

ITY

stakeholders

Project team

Preliminary stakeholder stratification

• Impact assessment• Stakeholder stratification•Change Agent Network

Risk Assessment

•Risk assessment framework•Risk assessment review•Realignment of stakeholder stratification

Deployment planning (risk‐based)

•Risk  & issue mitigation•Alignment•Enablement

Deployment

•Pull•Push•Sustainment

Main components of approach

9

• 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

Risk 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 planning (based on assessment)

•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

Deployment  (4 weeks or as negotiated with stakeholder group)

10

(Simple) Example

*Pull date: date when system is available for optional download by the userPush date: date when system is automatically uploaded onto a user’s machine (if the user hadn’t already downloaded it) 

1

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

Risk assessment

Scope of Risk Assessment [example]

Risk levels

Level 3

• Business Critical(e.g., financial, regulatory, safety impacts)

Level 2• Non‐critical Operational Impact(e.g., impacts to non‐critical processes )

Level 1• Limited Impact(e.g., impacts to users)

Data collectedDemographics of a particular group (e.g. Size, average skill level, adoption “comfort”,…)

Business impacts (operational/organizational)

Testing w/ level of effort

Identification of the level and mode of training that will be required

Identification of blackout periods

Potential need for concurrent migrations

Exceptions

RecommendationsEstimated # of weeks needed to mitigate all identified issues and risks

Assigned risk level 

12

Low risk deployments occur first, followed by medium risk, “unexpected” issues can be identified mitigated prior to deploying to high risk groups

13

Begin 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 reviews

Conduct readiness status of testing and mitigations- If “Go”, prepare for rollout- If “No‐go” establish timeline for remediation and future migration

Deployment planning

2

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 levelDeployment stats and trends monitored by project team (e.g., “adoption rates”, issues, …)Business monitors progress and provides updates at weekly meetingMost communications are channeled through the business and adapted to fit local cultureAfter action review conducted jointly by project team and integrated into the next iterationComplete transition activities

Deployment

* 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

Pull & Push [example]

15

Pull

•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•During pull period, continuously communicate process to be put on exception list (w/ business justification)•At week 3, review exemption list

Push

•If threshold is met, plan for push•Applications pushed to all users except those on the exception list

Post Deployment

•Offer “clinic”•Deployment Reps and project team conduct “after action review” of the deployment process•Reps document and debrief other reps and project team•Lessons learned are incorporated in the deployment process for upcoming iterations

16

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

Summary of benefits

Shared ownership, buy‐in, and accountability

Your thoughts & Questions?

About the presenterAllen Stines, PhDe-mail: [email protected]: www.linkedin.com/in/allenstinesBlog: 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).