People working with projects, programs, and agile teams have typically a development mindset – we love to develop new things. However, one of the key learnings for me has been the importance of the deployment of the changes we have developed. If deployment is missing, it is unlikely to actually reach the aimed business benefits.
With Strategic Development Portfolios, there may be many different types of changes to be deployed across the organization, here are few examples:
- Strategy deployment – creating awareness and aligning the organization to strategic targets
- Introduction of new IT tool impacting business processes and ways of working
- ERP rollout to a unit
- Introduction of new offering, products or services to markets
- Replacement of a legacy IT tool with SAAS service – impacting also business logic and processes
- New pricing model changes
- Changes in the roles and organization
- Cultural changes or changes in the ways of working (e.g. leadership behavior, lean and agile)
It is not enough to send a newsletter or create 10 min online training to be successful with this type of change. I will go through some of my key learnings from the deployments, I hope this helps!
People side of the change
One of the challenging parts in any strategic initiative is people side of the change. We tend to be so busy with the hard staff – concepting solution, negotiation with the vendors, development and testing and keeping the schedule that there may not be enough time to focus on change management. Today, many large transformation have also change management leads, which is wonderful – the importance of change management has been recognized.
Here are couple of things, which I have seen very beneficial:
- Engaging key stakeholders already during the development phase – co-creation, info calls, news letters, engaging teams early on in testing…
- Communications or support package for people managers – how is the change impacting our team, how to go through the change in our team meetings, how to follow up on change.
- Role based training materials – thinking about the messages and training materials from different roles view point, not just using generic materials which may not be a perfect fit for anyone. Creating modular materials, from where you can choose materials relevant for different roles.
- Feedback loops & retrospectives – when developing something complex and new, it is important to continuously improve. Collecting the learnings from the pilot phase and improving both the content and ways of working makes the rest of the deployments smoother.
- Overall high quality deployment package makes the change management easier – let’s review that part next!
Making it scalable via high quality deployment package
Documentation from the development project is not a proper deployment package. Deployment package should be created from the perspective of the receiving organization and to support the change adaptation within the unit.
Here are few components, which might be relevant for a deployment package:
- Task list
- Training materials (role based)
- Communications package
- Change management package for line manager
- Marketing materials
- Technical product & sales documentation
- Value proposition and sales support materials
- KPIs & criteria for success to be followed
- Supporting tools or IT solutions
Deployment planning as a collaboration
Organizations have also limits, how many changes can happen in parallel while running also sales and business operations.
- Align deployment plans with the units to collect also feedbacks on priority of your development, and other parallel activities. What would be optimal from the unit perspective?
- Budget also funding for deployment – do you need a rollout coordinator? Would you need to translate some of the marketing materials to different languages? Would you need a project manager or a new key user hiring in some units?
- Sometimes with large transformations, deployment may take years, as there are many organizational units to be considered. However, this may be also dangerous – business benefits are delayed, there are old and new solutions to be maintained, and also more and more changes may be required as time goes by. How to make deployment as smooth as possible – creating waves for deployment? Or perhaps engaging area organizations to scale up?
When would we need a rollout project and when release communication is enough?
If there is an existing solution or process, with well functioning regular release practices and an existing community of practice or a network of experts, there may not be need for a rollout project. Release communication may be enough to keep people informed, and key users or other experts are taking the needed training actions within the units.
However, rollout project may be a great approach, when:
- Change is impacting significantly one or more organizational roles
- Completely new IT solution is rolled out across different units
- Introducing a completely new business model or new type of offering, products or services
- Extensive training is needed or building up new competences within organization
I think deployment of new offering deserves an own blog, I will come back with that topic later!
Did you already notice the Free Online course? Have a look!
Strategic Portfolio Management 
One thought on “Don’t forget deployment!”