There’s a distinct difference between the two, but it makes a lot of sense to combine the two roles, as part of any project that involves widespread cultural change in a body of people.
A project manager steers; advises; oversees; and communicates about and between the project, the people it will affect, and the people affecting (and effecting) its progress. A project manager ensures that the thing stays on budget (time and money and other resources) and lives up, as much as possible, to the initial goals laid out by the stakeholders (ideally: the people who asked for this project and those who’ll be most affected). A project is defined as “an individual or collaborative enterprise that is carefully planned to achieve a particular aim” (thanks, Google). It has a specific lifespan, and stops when either the goal has been achieved, or those concerned have decided that it’s not possible to achieve that goal. Stop (or: do nothing when considering options at the beginning) should always be an option considered by competent project managers. The new functionality goes on to be managed by other people as “Business As Usual”, and the aforementioned competent project manager follows up a few months later with stakeholders on how the changes are functioning/ bedding in. Or not.
Two main project approaches are used in my business: Waterfall and Agile (while Lean Six Sigma is starting to make itself felt in the more manufacturing-equivalent areas of the organisation). A quick overview (of my understanding) of the first two can be found in the Appendix of this post.
Main point is: you have to gather your requirements well, no matter which delivery method you choose. And what most project managers (or business analysts if it’s a big project and you want an expert in gathering complex requirements) do is first get a broad brush statement of what’s needed, then drill down in successive stages, narrowing in on what those objectives mean in detail. In other words: you ask the same question several times, seeking more detail, gathering stakeholders’ priorities as an integral part of the process.
In addition: you need to test out the implementation, and be prepared to either send it back for corrections (there are always corrections to be made), decide which defects you’ll live with for an agreed meantime, or call full-stop and kill the project (something too few projects actually consider, let alone do); and risks and issues must be recorded and planned for rigorously throughout the lifecycle of the project. Again: the risks and issues recorded should also give you the option to full-stop, or at least pause while more resources are gathered.
Business Change Management is different from Project Management in that it talks about how to manage the shift in day-to-day working practices that will come about, usually as a result of a project (if you’ve managed this right!). It requires an insight into how people cope with change (usually badly – change (all change – positive or negative) is stressful to some degree; you can no longer rely on habit to carry you through, until you’ve learned the new way of things), and means applying techniques that will allow people to experience as little stress as possible during the transition and onward.
Without getting wildly technical, this requires good application of practical group psychology, including a few well-worn techniques that help people manage change:
2. Decide whether you’re going for a top-down or fully democratic approach. This is important. The top-down approach involves having a strong vision of the end goal and communicating it clearly to everyone, letting them know what their role is in the change and how they will be affected by it. Fully democratic means seeking people’s opinions on outcome, means, etc., giving them the autonomy to effect those changes, and being willing to change your mind as these new things come up.
Different changes require different approaches, but two important takeaways from this are: a) you need experts, no matter which approach you follow, b) the worst thing you can do is tiffle away in the middle somewhere, telling people it’s up to them but at the same time ignoring their requirements/ fears/ suggestions/ expertise and blocking their innovations.
Different changes require different approaches, but two important takeaways from this are: a) you need experts, no matter which approach you follow, b) the worst thing you can do is tiffle away in the middle somewhere, telling people it’s up to them but at the same time ignoring their requirements/ fears/ suggestions/ expertise and blocking their innovations.
3. Understand that all psychological adaptation to change follows the same pattern (along a timescale of anything from minutes to decades, even centuries) as that of grieving
Denial
Anger
Bargaining
Depression
Acceptance
and then a fun one for change which is Exploration of your new world. (In case you’re not aware, this is based on the Kübler-Ross Model of grief and loss.)
The important takeaways from this are that a) you need to allow people to grieve and celebrate the old way (no matter how shitty… people just got used to doing things that way, and they will literally have to change their minds in the form of rewiring brain synapses to alter habits and pick up new skills, no matter how small) in their own way and time, and b) you need to give them tools to get through those five stages smoothly and effectively. Keep telling most people they’re wrong to feel a certain way, for example, and they’re just going to dig their heels in deeper/ surrender to despair.
Denial
Anger
Bargaining
Depression
Acceptance
and then a fun one for change which is Exploration of your new world. (In case you’re not aware, this is based on the Kübler-Ross Model of grief and loss.)
The important takeaways from this are that a) you need to allow people to grieve and celebrate the old way (no matter how shitty… people just got used to doing things that way, and they will literally have to change their minds in the form of rewiring brain synapses to alter habits and pick up new skills, no matter how small) in their own way and time, and b) you need to give them tools to get through those five stages smoothly and effectively. Keep telling most people they’re wrong to feel a certain way, for example, and they’re just going to dig their heels in deeper/ surrender to despair.
4. Communicating regularly, proactively, and positively-but-realistically about progress and how that is leading us to the good place we all want to be in at the end of the process.
How does this all tie into Brexit? I hear you ask… Well, let’s spell it out more explicitly, since I’m pretty sure that the people concerned have not engaged any experts in business change or, for that matter, project management.
Firstly, in my opinion and experience, there should have been an intense period of working out the options for what Brexit actually means; maybe six months or so, before asking for another referendum, which laid out those options. Arguably that should have come first, but there’s rarely real harm in asking a broad brush question first, as long as you all know that you’re going to follow it up with at least a second round of questions. By “laid out those options” I also mean that there should have been clear advice from experts on the likely outcome of those options, in order for people to better understand them, where possible. This should always have been on the cards – they should have worked out that a Brexit majority was possible and laid down what the next stage was going to look like, so that no-one could claim it was people trying to weasel out of it. Among the options of the more granular set of questions should also have been “Do nothing/ remain in the EU”. As I said earlier: any competent project manager should be putting that on the table for their stakeholders, even if the answer is a resounding: any change is better.
(At this stage, it should also have been possible to drill down even deeper into a more granular understanding of people’s needs, given the majority answer to the second round of questions, but maybe that would have been better handled by experts. It depends on the outcome, obviously.)
Only then, in my opinion, should Article 50 have been triggered, if the overwhelming majority still said Brexit, and on which terms.
Secondly, again in my opinion and experience, there should have been a plan to either devolve the responsibility for carrying out the changes to people at regional levels, carrying on the process of making this a fully democratic process, or there should have been a very clear vision of the desired outcome and means to get to that laid out for people to follow.
(Personally, I tend to favour the democratic approach, but sometimes you’ve just got to say: sod it, this is the best way forward, and here it is. People trust authority, on the whole – that’s what it’s there for: stability and clarity of purpose, and removing the need for people to think for themselves (a discussion for another time, perhaps).)
However, yes, you’ve guessed it – in my opinion those in charge did that tiffling about in the middle thing instead. Combining the phrases “The Will Of The People” and “Brexit Means Brexit” is the very definition of treading the shitty middle ground between two solid and effective positions.
Thirdly, there was little or no provision or capacity for allowing people (48% of those who voted is no mean number of disappointed, shocked, unhappy people in an entire country) to pass through those stages of mourning – no patience, no protection, little effective reassurance (and significant amounts of that turning out to be false latterly – see Windrush generation issues, just for starters). Faced with a combination of impatient Brexiteers and devastated Remainers, they have managed to keep nobody feeling reassured over the last couple of years, let alone actually happy (except, curiously, those whose investments overseas keep them secure no matter what).
Cards on the table, in case you haven’t already guessed/ didn’t already know: I’m a Remainer. I consider myself, for a variety of reasons, European. That’s unlikely to change. But there are so many better ways this could have gone and us still be on track to exit the EU in a stable, strong, well-managed, actually democratic/ benevolently autocratic fashion where the majority of people were, if not happy, then at least assured that our Government was doing the best it could for the least worst reasons.
As for whether a Second Referendum would work now… my skeptic brain is fairly sure that this is too late. The time to gather more granular requirements is at the beginning of a project, during the initiation and planning stages. At this point, in my opinion, you’re looking at full steam ahead with a great deal of heavy duty risk and issue management lined up, or a full stop (at the very least a hiatus of about a year during which more planning, issue solving, and risk mitigation, etc. can occur). I guess that’s what any second referendum at this stage could ask: Full Steam Ahead, Full Stop, Pause for a year. (Obviously all of those are dependent on what will be agreed upon by the EU.)
Final note: there’s a technique that competent project managers should employ, which is called “Lessons Learned”. You bring as many representative stakeholders together as possible after the project is deemed a success/ officially been called to a full stop, and gather from them the following information:
What Went Well (there’s always something, and it allows people to celebrate successes)
What Could Have Gone Better (there’s always something, but the important thing is not to assign blame as such, while ensuring that it’s recorded in a clear manner that helps people not repeat the same issue, if at all possible)
Things To Do Differently Next Time (the future’s bright, what optimism shall we bring to this to ensure that anything of a similar nature goes even better?)
(Of course, if you record the lessons of history but fail to learn from and change your actions accordingly, there’s nothing much can be done.)
I’m not an economic or geopolitical expert. I’m not even a qualified group psychology expert (though I am a qualified project manager and business change manager). I can’t say with any certainty what the outcome of Brexit/ Remain (if that is still considered an option) will be on those fronts, but there are experts, and they need to be consulted, for risk and issue management at the very least.
However, I am considered an expert in my organisation on delivering good and constructive Lessons Learned sessions, and my rates are very reasonable…
Agile approach means, simply: gather the requirements and group them into modules that can produce small results as part of the whole. The whole thing is driven by resource (usually time), so that you aim to answer as many of the requirements as possible within a limited budget as possible. Prototypes are produced to allow for better agreement on requirements. Actual working solutions of parts of the whole are produced regularly and frequently so that stakeholders can view and feed back on the development. Testing is still done on the whole by stakeholders towards the end of development, but some projects also have user-led testing throughout, after each “sprint” is done. It’s particularly important here to prioritise requirements so that they can be grouped for these “timeboxes” in terms of criticality/ desirability and function. Advantages: proactive as well as reactive; engaging stakeholders throughout ensures better quality; you’re much more likely to hit your time target. Disadvantages: lots of people don’t understand what Agile actually means (they think it means: go fast, stripping away safety precautions); you’re potentially less likely to get everything you asked for; people can get a bit weary having to constantly test and feed back on developments.
Back to the main text
Firstly, in my opinion and experience, there should have been an intense period of working out the options for what Brexit actually means; maybe six months or so, before asking for another referendum, which laid out those options. Arguably that should have come first, but there’s rarely real harm in asking a broad brush question first, as long as you all know that you’re going to follow it up with at least a second round of questions. By “laid out those options” I also mean that there should have been clear advice from experts on the likely outcome of those options, in order for people to better understand them, where possible. This should always have been on the cards – they should have worked out that a Brexit majority was possible and laid down what the next stage was going to look like, so that no-one could claim it was people trying to weasel out of it. Among the options of the more granular set of questions should also have been “Do nothing/ remain in the EU”. As I said earlier: any competent project manager should be putting that on the table for their stakeholders, even if the answer is a resounding: any change is better.
(At this stage, it should also have been possible to drill down even deeper into a more granular understanding of people’s needs, given the majority answer to the second round of questions, but maybe that would have been better handled by experts. It depends on the outcome, obviously.)
Only then, in my opinion, should Article 50 have been triggered, if the overwhelming majority still said Brexit, and on which terms.
Secondly, again in my opinion and experience, there should have been a plan to either devolve the responsibility for carrying out the changes to people at regional levels, carrying on the process of making this a fully democratic process, or there should have been a very clear vision of the desired outcome and means to get to that laid out for people to follow.
(Personally, I tend to favour the democratic approach, but sometimes you’ve just got to say: sod it, this is the best way forward, and here it is. People trust authority, on the whole – that’s what it’s there for: stability and clarity of purpose, and removing the need for people to think for themselves (a discussion for another time, perhaps).)
However, yes, you’ve guessed it – in my opinion those in charge did that tiffling about in the middle thing instead. Combining the phrases “The Will Of The People” and “Brexit Means Brexit” is the very definition of treading the shitty middle ground between two solid and effective positions.
Thirdly, there was little or no provision or capacity for allowing people (48% of those who voted is no mean number of disappointed, shocked, unhappy people in an entire country) to pass through those stages of mourning – no patience, no protection, little effective reassurance (and significant amounts of that turning out to be false latterly – see Windrush generation issues, just for starters). Faced with a combination of impatient Brexiteers and devastated Remainers, they have managed to keep nobody feeling reassured over the last couple of years, let alone actually happy (except, curiously, those whose investments overseas keep them secure no matter what).
Cards on the table, in case you haven’t already guessed/ didn’t already know: I’m a Remainer. I consider myself, for a variety of reasons, European. That’s unlikely to change. But there are so many better ways this could have gone and us still be on track to exit the EU in a stable, strong, well-managed, actually democratic/ benevolently autocratic fashion where the majority of people were, if not happy, then at least assured that our Government was doing the best it could for the least worst reasons.
As for whether a Second Referendum would work now… my skeptic brain is fairly sure that this is too late. The time to gather more granular requirements is at the beginning of a project, during the initiation and planning stages. At this point, in my opinion, you’re looking at full steam ahead with a great deal of heavy duty risk and issue management lined up, or a full stop (at the very least a hiatus of about a year during which more planning, issue solving, and risk mitigation, etc. can occur). I guess that’s what any second referendum at this stage could ask: Full Steam Ahead, Full Stop, Pause for a year. (Obviously all of those are dependent on what will be agreed upon by the EU.)
Final note: there’s a technique that competent project managers should employ, which is called “Lessons Learned”. You bring as many representative stakeholders together as possible after the project is deemed a success/ officially been called to a full stop, and gather from them the following information:
What Went Well (there’s always something, and it allows people to celebrate successes)
What Could Have Gone Better (there’s always something, but the important thing is not to assign blame as such, while ensuring that it’s recorded in a clear manner that helps people not repeat the same issue, if at all possible)
Things To Do Differently Next Time (the future’s bright, what optimism shall we bring to this to ensure that anything of a similar nature goes even better?)
(Of course, if you record the lessons of history but fail to learn from and change your actions accordingly, there’s nothing much can be done.)
I’m not an economic or geopolitical expert. I’m not even a qualified group psychology expert (though I am a qualified project manager and business change manager). I can’t say with any certainty what the outcome of Brexit/ Remain (if that is still considered an option) will be on those fronts, but there are experts, and they need to be consulted, for risk and issue management at the very least.
However, I am considered an expert in my organisation on delivering good and constructive Lessons Learned sessions, and my rates are very reasonable…
Appendix
Waterfall approach means, simply: gather and agree on requirements and end state goal, give those over to the experts who can deliver this (in my job, that’s usually web application developers), they develop the whole thing, then present it for testing by some end state experts (preferably those stakeholders who use the system most closely and can apply real life scenarios to the new build), then make changes based on what the tests come back with. If it’s not up to scratch, start again – quality is the key driver, with an aim to get all requirements in place no matter how long it takes. Advantages: traditional and well-established/ -understood; stakeholders generally get everything they asked for; allows developers to really get to grips with the thing before any interference from the stakeholders; gives stakeholders a bit of a break while the developing is going on. Disadvantages: the black box of the development means that a lot of mistakes might occur without reference to the stakeholders; it might end up perfectly functional but not what the stakeholders actually wanted; you’re potentially more likely to go over your time limit.Agile approach means, simply: gather the requirements and group them into modules that can produce small results as part of the whole. The whole thing is driven by resource (usually time), so that you aim to answer as many of the requirements as possible within a limited budget as possible. Prototypes are produced to allow for better agreement on requirements. Actual working solutions of parts of the whole are produced regularly and frequently so that stakeholders can view and feed back on the development. Testing is still done on the whole by stakeholders towards the end of development, but some projects also have user-led testing throughout, after each “sprint” is done. It’s particularly important here to prioritise requirements so that they can be grouped for these “timeboxes” in terms of criticality/ desirability and function. Advantages: proactive as well as reactive; engaging stakeholders throughout ensures better quality; you’re much more likely to hit your time target. Disadvantages: lots of people don’t understand what Agile actually means (they think it means: go fast, stripping away safety precautions); you’re potentially less likely to get everything you asked for; people can get a bit weary having to constantly test and feed back on developments.
Back to the main text
