Hello Conor, I have a question, something I’m struggling with right now and it’s connected to the ‘6 page-memo’ that Amazon practices that I believe you are a big influencer of this movement? The context is this. I work as a Project Manager in a large consultancy organisation and it’s difficult to influence upper management unless you are the most ‘outspoken’, ‘well-connected’ worker there. However, thank fully when you show initiative and if that initiative works and people start to see it’s benefit, upper management can take notice and the new practice can be adopted. So, I was wanting to create this culture change from the bottom up by experimenting with these 6 page memos. I believe I’m well placed do so because my role is to bring together a cross-functional web development team and also liaise with the client to solve their tech problems and build something that meets their initial proposal. I seem to fall short when it comes to maintaining the practice over time. I’ve managed to start off strong and have a document that states why are we doing this and what’s important to the client, we call it a blueprint. What I find though is that these documents fall to back of mind when new problems come up in the project, then there are solutions that are proposed and they forget the why, the objectives and the outcomes and we end up down a different path than what was intended, it’s not a terrible outcome, but it certainly isn’t the best outcome that could be achieved. What am I doing wrong in my role? Do I need to have a document that repeats this information at a high level over and over until it gets into their subconscious? That way we can save ourselves time and headaches in going back and forth when solving problems and ensuring the project stays on tasks in the right direction. We have weekly meetings, but it’s more of a ‘task focused status update’ – aka. Mark have you done x,y,z. Jess how are you going with H?. People find these meetings boring and I find project status reports are also a waste of time because the team don’t want to look at them after the meeting when they actually need to because it tells them the dependencies and progress of tasks and when they need to step in. I find most people just want to do the work and I have been more effective in my project management when I do the old ‘face-to-face’. However this is not scalable and not very efficient. The project status update is also used to convey to my client the progress we are making so they feel confident that we are moving forward and towards the same north star we had defined from the start of the project. However I’m not convinced it does a great job of that either because it’s only timeline and task focused, instead of mentioning those high level objectives on a regular basis, I’m finding the client also gets stuck on the problems and adds in random elements to the mix that have nothing to do with their project objective. I guess what I’d like to learn is how do I structure and write documentation regularly to use to update both my team and the client to focus on the right path that was discussed and agreed on from the get-go? I need something that makes it very clear about the roles and responsibilities for the project, something that commands action and something that will be so simple people won’t just see it as a huge document full of writing that they want to skim past it. Does that make sense? A lot to ask for I know, it seems like you have a brilliant way of cutting through the noise and providing simple solutions, so I thought there was no harm in asking you. 🙂 Thank you for listening. Sincerely, Samantha