Love this! I’ve struggled with how to counter the binary “projects are bad, so we can’t have projects” stance people take, and this spectrum is great framing.
I really appreciate your ability to extract patterns from the mess. Contextual awareness and project-ish for the win!
I feel like most organizations struggle with those BMPs because they only implement the high coordination piece, some rigor, but not quite the “we are in this together” principle you defined. It’s a constant uphill battle with conflicting priorities of what teams naturally recognize as their daily work against the top-level pressure on this big thing we all need to prioritize now.
I like this framing. I could see it more useful by trying out different third dimensions. Within a company, I would add time to see how the other two dimensions change over time. Are we getting more project-ish?
Over a particular group of companies would be another possible axis. It could help us answer questions such as: Do larger companies always become more project-ish?
You could combine the other two to see how a market segment changes over time? Are we as an industry becoming more projective-ish?
I think the high-level advice is there, “A Big Messy Project necessitates the assembly of a dedicated project team adhering to the principle of "starting together, working together, and finishing together." How you do this will depend on your own company and situation.
Several principles for me Andrew (just my opinion folks!)
1. Everybody* invested must understand that things are going to go wrong. We do not have perfect foresight and it won't be a big obvious thing that derails the plan, it'll be a thousand cuts that caused the date to shift and budget to inflate.
2. You must have a closed loop management process, so decisions can be made within the BMP as quickly as possible. Independent design authorities, councils and steering groups are just additional delays. If you don't have the right skills in the team to make the decisions, then get the right skills in the team!
3. Allied to number 2, you need a tight feedback loop from whatever stage you are at, into the project management team. Ideally you should try and organise so that 'the work' is visible - and that includes things like RAID items, decisions... not just the implementation / config / build tasks. You don't want this stuff to only be visible when it's on a fortnightly programme status report. You need to have async communication so people can participate unhindered by meeting schedules.
I guess in short, where possible we should adopt the practices, techniques and processes from more modern agile delivery methods.
*And by 'everybody', I mean the leadership / exec.
Love this! I’ve struggled with how to counter the binary “projects are bad, so we can’t have projects” stance people take, and this spectrum is great framing.
I really appreciate your ability to extract patterns from the mess. Contextual awareness and project-ish for the win!
I feel like most organizations struggle with those BMPs because they only implement the high coordination piece, some rigor, but not quite the “we are in this together” principle you defined. It’s a constant uphill battle with conflicting priorities of what teams naturally recognize as their daily work against the top-level pressure on this big thing we all need to prioritize now.
I like this framing. I could see it more useful by trying out different third dimensions. Within a company, I would add time to see how the other two dimensions change over time. Are we getting more project-ish?
Over a particular group of companies would be another possible axis. It could help us answer questions such as: Do larger companies always become more project-ish?
You could combine the other two to see how a market segment changes over time? Are we as an industry becoming more projective-ish?
Nice to know a new word but would be great if you can share some wisdom on how to deal with messy projects ;)
I think the high-level advice is there, “A Big Messy Project necessitates the assembly of a dedicated project team adhering to the principle of "starting together, working together, and finishing together." How you do this will depend on your own company and situation.
Several principles for me Andrew (just my opinion folks!)
1. Everybody* invested must understand that things are going to go wrong. We do not have perfect foresight and it won't be a big obvious thing that derails the plan, it'll be a thousand cuts that caused the date to shift and budget to inflate.
2. You must have a closed loop management process, so decisions can be made within the BMP as quickly as possible. Independent design authorities, councils and steering groups are just additional delays. If you don't have the right skills in the team to make the decisions, then get the right skills in the team!
3. Allied to number 2, you need a tight feedback loop from whatever stage you are at, into the project management team. Ideally you should try and organise so that 'the work' is visible - and that includes things like RAID items, decisions... not just the implementation / config / build tasks. You don't want this stuff to only be visible when it's on a fortnightly programme status report. You need to have async communication so people can participate unhindered by meeting schedules.
I guess in short, where possible we should adopt the practices, techniques and processes from more modern agile delivery methods.
*And by 'everybody', I mean the leadership / exec.
Ha! I hadn't realised these were comments from two weeks ago. My fault for not keeping a closer eye on John's blog! :)