Episode transcript The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.
Ricardo (4s): Hello, everyone. Welcome to the five minutes PM. Podcast Today. I'd like to talk about generic and detailed planning. It seems to be very clear the difference, but let's try to analyze a little bit more. What is a generic planning? It's when you do a high level planning, you are not concerned about details, you're not concerned about going into the granularity of your project. You are a much more open to change. You adapt much faster, and this is the route of all these agile concepts and these agile methods. On the other side, you'll have a much more detailed planning where you, you are really concerned about small pieces.
Ricardo (45s): You are really concerned about having a, bigger control. Of course, if you detail more, you have less flexibility. You understand much better what you need to do, but you are much less flexible with the environment with potential changes. And of course, when I explain this quickly, you will immediately think, Oh, it's much better to do a generic planning. It's faster, It's open the other one is much more rigid. No, you need to understand which kind of project which kind of contract you're talking about. So I want to explain to you three basic criteria that you can use to understand if you should move to one side or another one.
Ricardo (1m 27s): The first one is the type of contract. For example, when you are developing a plan or project that the contract is more open, for example, you pay per hour or you pay per hour per resource, or you have a more flexible payment schedule. You can challenge yourself to be more agile. It's a work without a very detailed planning. And the other side, if you have a fixed firm price, very strict, this type of contract, will move you to a more detailed planning because if you don't plan very well if something happens, you will pay. In a more generic, when the contract is more flexible then you are transferring the risk to your client that will pay for that.
Ricardo (2m 11s): So this is the first criteria. The second one is team experience. If you have a more experienced team, for example, software development, it's very interesting. If you have a very strong software development team, you don't need to go into the tails. You can become more agile, in a much more teamwork doing, for example, scrum and move it. That's fine. But if you have a junior team or a massive big team with all sorts of skills, then it's not so easy for you to keep things open because people will do mistakes. Then you go more to the detail. And last but not least the third criteria I use is the size of the damage in case of failure.
Ricardo (2m 54s): If things go wrong, really wrong, bad, can you afford the damage? If you can afford and adapt, you can go into a more generic, an open because you can't adapt yourself, for example, on software, if something goes wrong, you can fix that. Maybe you can fix that code line. You can adjust. But if you have very small flexibility in the damage is massive than you need to go to the detail. Let me give you an example that I love. All of you have heard about the James Webb telescope of NASA. NASA is replacing the Hubble telescope with a new, much more powerful telescope.
Ricardo (3m 35s): And it's around an investment of $10 billion and it's that the size of a tennis court. But there is a very sensitive and scary problem. When they launch the James Webb. It's over there is no way of maintenance of the telescope because the orbit that the telescope will stay is not reachable by an aircraft. Let me explain what do I mean by that? If something goes wrong, if they need to Polish Mmm, the mirror or is it if they need to adjust it's over, it's $10 billion lost.
Ricardo (4m 16s): So what do they do? They need to have an extremely detailed plan. Extremely. If you go to the NAZA website and looked for more information about the James Webb, you will see that they have all the structure, project office, project management office project manager and a full team of scientists and this. Because this becomes critical because the damage in case of failure is so massive that they need to detail absolutely everything. And this is why it takes so long to do this kind of project. But at the end you will ask me, Ricardo, I don't work for NAZA. I don't build James Webb telescope. And at the same time, I don't want to use, go, horseman, no planning and anything.
Ricardo (5m 1s): Is there a solution for normal people in normal projects and the yes. And this is what I use in my life. It's the middle ground. You don't need to detail every single thing, but you don't leave things open because if you open twenty different things there may be a high risk. So the middle ground, and this is why Today I always say I use the hybrid models. Hybrid model is a mix between agile and more control. So sometimes I mix, I put a little bit of spice on Prince too, a little bit of PMBOK, a little bit of scrum, a little bit of agile, and even a little bit of no planning at all.
Ricardo (5m 44s): And then I built my solution, my solution to that specific project. So I know where the risk is very big. I prepare little bit more where the volatility is very high I leave it more open, and this is exactly the fine tuning that differentiates a successful from a failure project. So don't try to say, Oh, I should be generic because it's fast. Of course, it's a very fast, but maybe you will pay a high price at the end. If you detail a lot, it's much more costly. It requires much more effort, but at the same time, it gives you much less flexibility. So you need to understand how do you balance that?
Ricardo (6m 26s): This is why I always say Generalization is good, but it's bad detail. It's bad, but it's good. There is no solution that will feed and solve all your problems. Think about that when you're doing your next project, I hope you enjoyed this podcast and to see you next week with another five minutes PM podcast.
