 I'm going to show you now how not to plan a project. This is directed to project managers who sometimes assume that the way we break down the project when we plan it has to do with the way we manage it. Let me show you what I mean. Sometimes let's say as a project manager I have a new project called XYZ. Some project managers ask themselves, OK, well, how am I going to manage this project? They say, well, according to PMI, the Project Management Institute, Project Management Processes I'm going to break it down into initiating the project. To manage it, I have to initiate this project. So I'm going to initiate it, plan it, execute it, control it and close it. This is how I'm going to manage the project. So I might as well break down this project into these process groups. So what they do when they break down the project into their word breakdown structure, they break it down into initiates. This project I will initiate it. I want to plan it. I want to execute it, control it and close it. And they assume wrongly that these are my project phases. This is not right. This is a mistake. This is wrong. You should not break down your project into project management process groups. This is how you manage your project. This is not how you win the end deliverable. The end deliverable is built through what we call a project life cycle that shows me that core product development processes, not the management processes. It's in simpler terms. Think about it this way. Any project that you are doing, whether you are doing software, you're building a nail plane, a car, a house, how you manage the project will always follow these project management process goals. So just to tell me that I'm going to rate this project, I'm going to initiate there, execute, control and close. There's not going to be anything about what you're building or how you're going to build it. So to break down the project into project management process groups and assume they are project phases or that this is my project life cycle, this is and this is a pitfall. So what should I do as a project manager? As a project manager, you should first of all get to the least in your core breakdown structure and focus more on your project life cycle, how the project end result will be developed. This depends on the type of project you are doing. For example, if you are building a software, you would have to go ask the technical experts what software development process are they going to use? Are they going to use the waterfall method or are they going to use the rational method and based on that decide on the phases. If I'm going to build a house, then the project life cycle should reflect the different phases of building a house. For example, instead of saying initiate, plan, execute, control and close, your project life cycle should say, for example, design the house, foundation work, skeleton work, finishing, etc. And I'm not putting these as the way to build a house. I'm just giving you an example. If this is the way I build up my house, I will put design, foundation, skeleton, finishing. The important thing is to have my project life cycle reflect the end product that I'm going to deliver, not reflect how I'm going to manage. Now anybody who looks here can get an idea that I'm talking about a construction project. If I only had the initiate plan, execute, control and close, nobody can tell what I'm talking about. And this is a common mistake that project managers do when they develop their project plan and develop what we call the workplace construction. Now somebody might ask, how do I account for project management work? A good way to do that is not to put it in the call of your project life cycle. You can just add a box right here, or at the end, if you would rather, and call it project management. This way you can plan a project properly, not by reflecting your project management process rules as a project life cycle.