Whenever you take over a change of any size, you spend some time getting to grips with what has gone before.
As an aside – the ability of an organisation to pass a project (programme, workstream, change) from one person to another and be confident that there will be a decent continuity of knowledge between the two people is a key marker of maturity in change leadership.
I like to start by getting to know some of the people on the change, because that’s after all the only way to get any change delivered: working with people. You find out a lot, often things that aren’t related to the change itself or their ability to work. But directly and immediately relevant: you also find out things which aren’t documented. In my experience, always. It doesn’t matter how good the handover has been, or (at least so far) how comprehensive the documentation, you’ll always turn up something extra by talking to people – well in fact, mostly by listening to them.
Listening is in every field a key leadership skill.
You can find out how people feel about working on a project (even if that’s not what they are talking about) by what things they think you ought to know. You can find out a surprising amount about their ambitions and career development goals in some cases – information they just don’t share with their line managers for a variety of reasons. And most likely you find out things about the change you didn’t already know, from the documentation, or from the handover.
In an Agile project you often get to find out things like which person estimates high in the planning you do (I personally like planning poker, but other methods work too). You can find out little things that help you to motivate people – that Jane likes coffee, that Bob likes Early Grey Tea (and doesn’t like Star Trek), and that Sam can’t resist cakes or biscuits, but really wants to. Most of all, you can find out how coherent a change team has become – how much they have gelled – by the way they talk about each other, and about the change.
Or, and this comes back to the title of this article, you can find out that the team don’t agree on what the goals of the change are. You won’t find that documented in quite that way in most handovers – and a lack of transparency in the culture (we don’t want to hear bad news) is often at the root of that. With any kind of waterfall project, a vague, badly understood scope, is a sign of Bad Things. It’ll surprise some people to hear that it’s as bad in Agile too, but exhibits itself in a different way.
In all organisations – if you know differently, please do let me know! – there’s a limit to the resources available to bring about any particular change. In waterfall style projects that’s often set up front, before you really know the detail of what you’re going to deliver, and at an early stage you try to estimate how badly wrong you’re going to get it, and call it contingency. In pragmatic Agile, it’s often the case that you get given enough money for a set number of sprints, and a relatively fixed business goal, and you do your best to achieve it. (In platonic Agile, where the world is organised entirely around Agile, you don’t have to do this because you start earning real business value along the way and people are happy to fund you forever or what passes for it). Sometimes the budget cut off expresses itself in a different way – a restriction on the number or size of teams, periodic reviews of value achieved – but in principle there’s a limit to the blank cheque, and you need to deliver within that limit.
In waterfall, everyone expects you to come back and ask for more money at some point. (I know that it doesn’t always happen, but it’s common). In Agile, and for good reasons, the dynamic is different: but even in Agile, if you don’t focus on what your business goals are, on what you are trying to solve as a problem, you will drift. In neither case is it the responsibility of the people I talk to when I’m taking over a change to either fix or even identify the problem. Some do, some don’t, I consider it a bonus when they do. However, change leaders can diagnose that this problem exists when many people you talk to have an idea what the scope / goal is, but they are all different. (If no one has any idea, the problem might be this, but it might also be a terrible communication culture, and that’s entirely too common too).
If you take over a change, and find this problem, you probably just found your top priority thing to fix.