|Tweets by @itSMFUK|
|Autonomy with compliance|
Autonomy with compliance
When we introduce new processes, compliance can be a challenge. How do we get our teams to do what we need them to do? Heavy-handed mandate (“do it or else”) can result in a box-ticking culture that delivers the mechanics of a process without delivering the real value we were hoping for.
In his book Drive, Dan Pink tells us about the three elements of intrinsic motivation: autonomy, mastery and purpose. We train our people and help them grow their expertise (mastery), we share our company and departmental visions and show our teams how they contribute towards them (purpose), but what about autonomy? How can we allow our skilled IT professionals to exercise autonomy and still ensure they comply with processes?
I faced this conundrum recently while establishing a new Service Introduction Framework with a technology group. The framework provides a series of interactions, aligned to development and engineering milestones, to make sure the right conversations are happening, with the right people, as early as possible. Using the framework should result in service design happening in tandem with technical design, service acceptance criteria being defined and built into project plans as early as possible, and no nasty surprises in the run-up to go-live.
The changes being introduced in our group can vary wildly in scope and complexity, from a small update of a system utility to a whole new user-facing application, so there will never be a “one size fits all” template to follow. The framework needed the flexibility to allow people to use their domain expertise and their good judgement to decide what’s appropriate to their project. After all, if our work could be reduced to a set of inputs and a function that generates an output, our jobs would have been automated by now.
The framework was launched gradually, targeting only a few project teams to begin with, but the early feedback was surprising, with skilled, experienced people asking about things which seemed obvious. Many of the questions that came up could be answered just by talking to other stakeholders to understand or clarify their needs, rather than looking for the solution in a manual.
Presented with a new way of working, people often look for the comfort of certainty – “if A happens, do B”. The lack of such rigid guidance was disorientating, but in this case there would never be detailed procedures at that level. A colleague summed up what we saw when he jokingly suggested we should “write a procedure document to tell them they’re allowed to think”.
On reflection, it wasn’t such a far-fetched idea. None of our framework documentation actually told people – explicitly – that we expected them to use their judgement. In an organisation with such strict regulatory compliance requirements, where new processes usually involve some kind of form-filling, it was hardly surprising that they didn’t instinctively ‘get’ it.
If you’ve ever trained in Project Management using PRINCE2, you will have learnt seven principles of managing successful projects. The specifics of PRINCE2 aren’t important here, but using a principles-based approach creates a method that can be scaled and made appropriate to any organisation or project. There’s a lot of flexibility in how to apply the principles, but if the principles aren’t being followed, it’s not a PRINCE2 project.
I realised that borrowing from that approach could help people adopt the new framework without needing detailed procedures, so I started work on a set of Principles for Service Introduction.
By looking at the goals of a successful introduction, then examining the cases where we already met these goals, it became apparent that collaboration, communication, openness and common sense were the behaviours most important for success, along with clarity of roles and requirements. These formed the basis of our 11 principles.
Now when presenting the framework to people for the first time, we emphasise the principles first. The framework activities (tick-boxes, if you like) are important, but not all of them are required in all situations, and judgement is required to choose which are appropriate. But a solution that satisfies the principles is always a good solution.
With a complete set of principles, supported by our managers, teams are now more confident that their judgement on ‘the right thing to do’ won’t be second-guessed, and this leads to more confident decision-making. Better still, feedback shows that relationships have improved between the project teams and the teams receiving handover; the principles are being used to hold each other to account where it matters, without getting bogged down over unimportant details.
By emphasising principles over actions, we equip and empower people to make good decisions. We get compliance with – and more importantly value from – our service management processes, taking advantage of the expertise in our groups, not stifling it.