While many leaders are committed to a digital transformation, plans can easily get derailed before reaching execution. CIOs and executives, alike, should consider a different approach—one that takes into account the human and behavioural complexities underpinning this challenge. In this session, we’ll share stories of leaders who have managed successful IT transformations and their lessons learned along the way. We’ll address how to build skills among your IT staff through training and certification. We’ll also discuss ways to take advantage of collaborative workspaces, and best practices to aid in an effective implementation.
Bert Weyne, ICT Responsible Application, Manager, Agentschap Wegen & Verkeer
Thomas Blood, EMEA Enterprise Evangelist, AWS
18. 13 Biggest Challenges
When Moving Your
Business To The Cloud
- June 2017 article
People and Processes
“When it comes to cloud adoption, the
biggest challenge isn’t technology —
it’s the people and processes that
must change and adapt.”
20. • Time-to-market
• Inflexible platform
• Technical debt
• Unplanned work
• Customer experience
• Collaboration
2 months per release
Months to procure/provision
60 – 80% of effort
Outages, bugs, compliance
Performance and outages
Integrating with other business
units is technically difficult
Our old troubles
High cost & low productivity
21. 1. Embrace cloud
2. Standardisation & automation
3. Microservices architecture
4. YAGNI (You Aren’t Going to Need It)
5. Use the right tool for each requirement
6. Use out-of-box functionality whenever possible
7. Cultivate DevOps
8. “You build it, you own it!”
Our new principles
Think Big, Start Small, Go Fast
22. 1. Embrace cloud
2. Standardisation & automation
3. Microservices architecture
4. YAGNI (You Aren’t Going to Need It)
5. Use the right tool for each requirement
6. Use out-of-box functionality whenever possible
7. Cultivate DevOps
8. “You build it, you own it!”
Our new principles
Think Big, Start Small, Go Fast
23. Embracing cloud
“If you want to make enemies, try to change something”
– Woodrow Wilson
... especially from the
OPS side.
Turn your issues
into opportunities,
(or, strike when the
iron is hot!)
25. Hiring the right people to run your cloud
=> You want experienced ops people with high dev experience
=> You want them to be creative, explorative, and inspired by cloud
=> You want them to be eager learners (they follow the webinars)
=> You want them “lazy” (they’ll standardise & automate every bit)
My big stumble: PEOPLE
26. - Why: serve your customers (and compete) more effectively
- What: deliver applications and services at high velocity
- How: tooling, automation, E2E ownership, continuous integration&delivery
DevOps
27. - Why: serve your customers (and compete) more effectively
- What: deliver applications and services at high velocity
- How: tooling, automation, E2E ownership, continuous integration&delivery
- Outcome:
=> Automation
==> Highway speed IT development
===> Super active shareholder and owner group
====> High quality, secure, robust IT services and delighted userbase
DevOps
28. - Technology is a commodity; focus on your vision and choose what fits best
- Turn burning platforms into your allies
- Don’t hire so-so people; hire the best, hire inspired ones
- Be fully committed to your customers, they’ll be committed to you
- Make your app dev teams E2E owners of their apps
- Turn your ops at least 80% into the infra DEV team
- Go incremental and release frequently
- GO FAST!!
Key takeaways
Scope of the change - Position as “not all change is the same”
Based on what you’ve heard over the last several hours, where would your cloud initiative fit in this spectrum, show of hands
Improvement type change, transactional, or transformational
Improvement change: Focus on changing toolsets:
Examples: ERP upgrade, Blackline, revenue recognition systems
Improvement of “what is”
Sub-system change focused
“New state” is an enhancement of prior state
Transitional Change: Focus on changing toolsets and skillets (affect changing toolsets has on changing skillsets)
Examples: Electronic medical record systems, product/service redesign
Design and implement a new state
Dismantle old state, transition process
Process value stream change focused
Defined timetable
Transformational Change: Focus on changing toolsets, skillets, and mindsets (affect changing toolsets and skillsets has on changing mindsets)
Examples: Business model changes, shift to high automation, customer experience redesign
Current state and worldview modified
New state unclear; “discovered” during process
Major organizational systems change focused
Fundamental shifts in strategy, operating model, processes, views of customers and performance, leadership, governance, culture
Phase out what is shown on the screen
Do a polling question here
Explain why cloud represents a transformational change
This shows what work is required
Improvement change – required solution drivers:
Change communication
Change leadership
Project management
Training
Change leadership
Transitional change – required solution drivers:
Change communication
Change leadership
Project management
Training
Change leadership
Process design
Transformational change – required solution drivers:
Change communication
Change leadership
Leadership alignment and sponsor plan
Overall change management strategy and plan
Training and orientation
Organization design (leadership, development, cloud governance, culture)
Human resources strategy and support:
Targeted role redesign
Transition readiness for impacted orgs
Talent acquisition strategy
required – that the scope of the work increases, the bigger the change initiative
Align system of Reward:
Elements that are explicit (written/communicated/discussed)
Elements that are implicit (behaviors that live on because they are being encouraged or discouraged in some way)
You will want to define your desired cloud operating models and IT roles--and how they will evolve--early in the migration process.
Now we’ve added in the more detailed functions of each… and you’ll see that the CBO is responsible for a function called “on-boarding” which is the function that will help the Business Services on-board to consume the Cloud Services that power their applications.
That means, in addition to EA and Goverance, your CBO needs to be made up of action-oriented individuals that are capable of “doing” and not just advising.
Next, you’ll see in the Cloud Engineering function, a break-down of more detailed functions around Infrastrcuture, Operations, and Security... These three functions are the pillars in which any Cloud Service operates upon.
Inside each of these functions are common activites like Architecture, Dev, and Operations. Remember, this is not an org chart, it's functional only.
Next, let’s take a look at the typical tasks that these functions address...
So, what is Change Management?
Change Management is simply “Applying tools and processes to the people side of change to transition from a current state to a future state to successfully achieve a particular outcome.”
Mobilize Team / Align Leaders
Objectives
Confirm sponsorship
Secure resources, expertise
Form strong coalition of leaders
Build momentum
Key Actions
Form team to lead change – executive sponsors, stakeholders, line leaders, PMO, change management, communication, training, etc.
Establish program charter, roles, milestones
Build guiding coalition, mobilize leadership
Shape program governance structure
Assess and align change leadership roles
Envision the Future / Engage the Organization
Objectives
Articulate vision and roadmap for transition to Cloud
Mobilize organization, build commitment, create change urgency
Establish communication channels to gain and maintain buy-in, support and participation throughout entire transition
Key Actions
Leaders communication future Cloud vision (via comprehensive messaging plan)
Impacted business leaders reinforce new op model (process/tech/org)
Identify/assess impacted stakeholders
Enlist and mobilize Change Champion Network
Drive ongoing communication, feedback – two-way conversations
Address “How does this impact me?”
Celebrate progress and control issues
Enable Capacity / Make it Stick
Objectives
Ensure successful transition to Cloud
Align IT org structure, roles, processes with AWS Cloud platform
Ensure all IT staff/key stakeholders can operate in new environment
Ensure Cloud benefits and objectives are achieved
Key Actions
Identify change impacts to IT roles, policy, org structure, process, etc.
Modify IT roles, org structure, job descriptions and processes (if needed) to support AWS Cloud
Align IT staff to new operating model
Develop and implement targeted training
Setup measurement structures
Measure and evaluate outcomes
Course correct where needed
Key Steps and Considerations – (right side of the slide)
Build a Coalition – Cloud Center of Excellence (CCoE)
A team of open-minded change agents, tasked with initiating and implementing a fundamental shift in how the organization functions
CoE team should evolve as a business progresses through the stages of transformation (cloud adoption)
Diverse and cross-functional representation is key
Big picture thinkers who are ready to lead business transformation
What does a CCoE do?
Creates, Evangelizes, and Institutionalizes Best Practices Across an Organization
Centers of Excellence begin as a group of like-minded change agents, committed to orchestrating critical business change throughout an organization
Establish patterns and frameworks from which leaders can operate
Set governance and compliance standards
Creates scalable approaches to how an organization’s cloud technology strategy is implemented
Why is a CCoE Important in the Journey to Cloud Adoption?
Defines how an organization builds and executes their cloud strategy
Creates a dedicated team with single-threaded ownership
This approach is flexible and it’s team makeup will evolve as the organization marches through the stages of transformation
Key Steps and Considerations – (right side of the slide)
Paint a Compelling Vision of the Future
Successful change requires a shared vision
A vision unifies an organization and provides a clear direction
The company vision is the anchor by which all change should ultimately connect
Connect change initiatives to the company’s vision
Create a sense of connectedness, so the proposed initiative doesn’t feel outside of the current direction or like it’s “just another complex, time-consuming, project”
Establish a clear, simple, and compelling statement of where we are going
Best Practices
Communicate the Vision (often)
Form a clear and consistent communication plan
Change does not gain traction through one initial kick-off communication
Newsletters and sporadic updates to small groups is not enough
Communication and day-to-day execution must be closely aligned
People must believe that real change is possible and beneficial to them
Incorporate communication into regular rhythm of the business
Link daily activities back to overarching vision
Continuously promote transformation and communicate victories
Dedicated change resource in your Cloud Center of Excellence
Leverage multiple communication channels
Town Halls
Office Hours
Email
Videos
Blogs
Communicate regularly
Key Points and Considerations – (right side of the slide)
Institutionalize new approaches
- Lasting change requires anchoring to shared company culture and values
Demonstrate regularly how migrating to AWS will increase performance
Draw meaningful cause/effect connections and communicate them regularly
Create a communication plan early in the project
Anchor to regular communication rhythm of the business
Management meetings, team meetings, all-hands meetings, company newsletters
Hire with the future-state in mind, not against old standards
- Consider all aspects of your operating model
Best Practices: Training
Consider not just your CoE for enablement but your infrastructure and application organizations.
Customers who have driven large scale training efforts have found that point of need training worked more effectively over mass enablement.
AWS Certifications is a good forcing function for recognition and to demonstrate proficiency.
Stage 1, I had some personal POC’s running on AWS. At a certain point we had an issue with the outsourcer of our websites (somthing got sour and we were blackmailed they’ll take the sites offline). We didn’t want to give in, and I brought relief with my personal AWS account.
Stage 1 went on and new little projects got on AWS on different accounts (we liked the flexibility)
Stage 2, we saw it our future and started thinking how we would organize our cloud, how to procure it, business case for Agency management, etc.
Stage 3, get Top Management approval, and work on your migrations, prepare you apps (cloud native), etc.
Stage 4, optimize your cloud, go serverless ….
To start of, you need a VISIONARY with kind of a work moto (especially in GOV I think), you must have balls and be persuasive.
No real troubles with the DEV teams, they are demanding, they normally are eager for move to cloud.
They usually are pulling for progress (docker, java 10, psql 10, etc.) They want progress
Certification is valuable, although my people aren’t. I for sure know they possess the required knowledge.
Above that there is plenty of AWS documentation available (use cases, etc.)
For the end users and the business, everything (can be done) quite transparent you don’t really need to take them in account in the cloud move.
But after the cloud move they’ll soon become aware that there’s another engine behind their applications.
They’ll notice better performance, higher reliability and most of all a much more eager and agile development team behind their applications.
We always have been very customer oriented, but the cloud move really made the customer base very active.
Before they were reluctant and had little confidence is our activities, but now they are very pleased, very active and thriving.
Tooling: build tooling, deploy tooling, log tooling, monitoring,
E2E ownership (no silos), Dev teams have insight in everything concerning their app, in minutes they can deploy new versions.
(everything version controlled and reproducible)
incremental development and frequent releasing
Ops becomes your infrastructure Dev team (80% they work on new/improve infrastructure services, 20% issues)