Many of us are familiar with the transformation life cycle exemplified through MSP®. There is plenty of language to use - e.g. ‘identify’, ‘define’, etc., or ‘current state assessment’, ‘vision and strategy’, etc. Clearly this is good practice, but how definitive we can be with this language or implied approach depends on the transformation mandate we are working upon.
For example, if we are doing something known, where there is a model/framework available for the transformation we're attempting – then we're perhaps addressing problem more than opportunity – we focus on orchestrating, aligning, selling, motivating, delivering, communicating etc. We might not need to be very innovative – we may be in simple transformation management domain.
However, there are transformations (or aspects to our vision and strategy) that are not known, where there is no model / framework, where we are addressing perhaps opportunity more than problem. We may not be doing fundamental invention which carries a lot of risk/expense – but not far off. We may not have the knowledge or experience in house to deliver the transformation – and we may have to generate that – and Innovate. We may not have a grandiose vision – but we may have a series of opportunities offered by circumstance or technology that we can exploit. Moreover – it may well be that the conventional business analysis/business/solution architect approach may just not work – as what good is it asking a business what it wants and offering to deliver it from ‘known’ if the business concept hasn’t even been ‘imagineered’ yet?
For example – technology availability. Cloud-based solutions and latterly artificial intelligence (AI) have given us potential to address matters we didn't even know we could. AI for example, has people excited and terrified both at the same time – with massive possibilities for helping a programme sponsor spot issues, to fixing failures in our nervous systems. Another – dare I say – Brexit (should it have happened by the time someone reads this) – giving us a whole bunch of challenges that are emerging. We need creative behaviours to address both. We will have to be innovative in how we respond to both scenarios.
So, to innovation. It is often said ‘innovate or die’, which isn’t meant to be taken literally - but it indicates the importance of innovation to business life. Thinking ‘out of the box’, it can be bottom up out of business-as-usual or project endeavour (e.g. “I’ve had this idea and I think we could try it this way” and “I did this for one project but I think it can be used such and such”) – and top down in response to challenges set (e.g. “Folks – we have to improve our green footprint – can we support this by reducing our travel to work/use of office space – ideas anyone?”).
But how does this get overseen? There is plenty of tech to enable challenges to be set, ideas to be captured and prioritised – but how does necessary effort get allocated (or is it a case of smash and grab of peoples’ time/good will?). How do we prevent clash or duplication? How do we encourage and channel? Do we have the culture for it? Can we do this outside of, or with controls needed for more usual project? How do these items fit within our corporate programme or even our local improvement objectives – and most importantly – how do we know this is valuable? If we are not managing it within our governance framework – how do we direct/control it at all?
In my opinion – innovation management – the process that welcomes innovations into life – needs to be considered as a specific activity and aligned with programme management, delivered perhaps with an agile mindset to projects (but not necessarily using agile tools or specific methods) so that we can encourage, lead, inspire and generate innovation that truly helps our business - and is sustainable. We may see ideas sparking, but it may be that with a support framework which is usually more about ‘constraint and assurance’, we need to alternatively provide support in the form of bounded ‘energy and encouragement’ to enable more than check (although both are needed to a degree!).
So – does this need to:
- Be led/driven/supported by a new function within our business?
- Be an extension to the programme office?
- Pop up and disappear with our transformation programme?
Or does this become a behaviour that we culturally embed in our business, project and programme teams?
Find out more: this and other topics will be discussed at the APM Programme Management SIG conference: Transformational Programme Behaviours and Values, held on Thursday 14 March.