Overview of Project Management
What is a project?
It’s a temporary endeavor that has a defined start and end date. That has specific objectives to be completed within certain specifications. Has funding limits, let’s be honest, every project has some type of budget. Consumes resources regardless of how much is consumed. And creates a lasting outcome for the organization, client, or stakeholders. So what constitutes a project? It can be the development of a computer software program, the development of a new product, creating a movie. Or designing, building a factory or a refinery. As a matter of fact, the designing and creating of this course can be considered a project. It had a defined start and end, had a specific objective, consumed resources, and created a lasting outcome. So why are projects at the heart of what engineers do? Because engineers primarily work on projects where they must be able to solve problems, manage relationships, make decisions, and communicate with their team. Which culminates with what we hope is a successful culmination of their project.
Project management, the ability to manage complex technical projects, is a requirement of engineering leaders, this is important. Good project management encompasses quality, cost, schedule, and programmatic alignment. Without oversight in these areas, your project will struggle. So what are some of the consequences of poor project management? Lost revenues and profits, contract penalties, higher costs, damage to your company’s reputation, resource waste, and you may lose your clients.
Now, let’s look at a basic design process,
first, you conceive the product. Then you design the product, and finally, you build on the product based on your idea. This is very similar to the project management process. The first phase of the project management process is initiating. This is where you start the project management process by developing a project charter and identifying your stakeholders. Then comes the planning phase, where you develop your project management plan, develop a schedule, estimate costs, perform risk analysis. And plan how you will manage and communicate with your stakeholders.
Next is the executing phase, where you and the people in your organization will perform the work. Perform quality assurance, identify and manage your project team, manage communications, and procure the necessary resources to complete the project. And now that the project’s ongoing, you’re going to have to monitor and control the process. Implement a process to manage change, control costs, and schedules, control risks. All while ensuring that you maintain quality control. And finally in the closing phase is where your project will be completed. And you’ll be able to assess the final project against your original plan.
Projects are a human adventure. It’s like a good movie. You can find everything excitements, issues, conflicts. I mean, doing a project and succeeding in a project is one of the most fulfilling experience we can get. For some of the projects I’ve done, people asking me year after year too with all this. But are there rules to do the project? How should you look at the project? Let me start with one story. We did a strategy for a travel and tourism company and we decided that we needed a new platform, a mobile platform. It was July 1st, new items were continuously appointed and came to see us and ask us what should I do first? And we told him, we have decided together that the platform would be live on May 10th. We are on July 1st. The first thing you need to do is to find a place to host 100 people for October, because beginning October, 100 people will be working full-time on the project. At the time we’re five on the business’s side and ten on the client’s side. Actually, he trusted us, and he went and did it. And by October, the project was running at full speed. But because time was so short, with the CIO, we decided to break the rules. We decided to do a trade-off on requirements but not to tell the business. We decided to go for a very simplified architecture that would be scalable, but not up-to-date or state-of-the-art. We decide to work with X and L companies, but not on a fixed price basis which was a constraint of the company, but low time and material because we didn’t know what to do. The project was a big success. The question I ask myself after that was did we really break the rules or did we do it as it should be done? To do a project, you need some rules, and you need to optimize three things. Business requirements and quality, delay, and cost. It’s very difficult to balance these three but the many findings, I have over and over and over when I’m doing the project. Then the key focus should be time because time is a very good metric. If you say you will deliver something by the tenth of May, this is something that everyone can see. Now, what exactly will you deliver by the tenth of May is more difficult to apprehend. So I would argue that one of the main parts to optimize is time and delay and actually, if you are mastering the delay, usually you master the budgets. Because the question is, you can not spend that much in a short delay. If you look at this picture, which is very important when you are doing a project is to define when you want the requirements, and what are those requirements? Are they must have or are they nice to have? It starts to be a very good discussion with clients. And you should put in place what we call the trained model. As you see in this cartoon the trained model is something that is both very interesting and very difficult. The train model concept is quite simple. The train starts on time and arrives on time. So time will be managed. But the flexibility will be about the content. We should decide with our business, what are the critical functionalities. This one, as you can see, will arrive on time. They will go smoother in there. Then there will be some nice two R functionalities. If we have time to do them they will arrive if not, they will be for the next version. And there is also a self-type of content. There would be functionalities that might be necessary one day. Well, we decide from the start that they will not be part of this version. If you can have a dialogue like that with a business, then making the project much more simple. Instead of having something very complex, you have something you can break down into parts. And you can make sure that the satisfaction of the client will be met when the project will be done. And then you have the flexibility to cope with the things that will happen during the project. Because there is always something happening, technical issues. That’s hardly the case, but it can happen.
A governance issue, changing business requirements, a people issue that project. So what are a few rules of project management? The first one is, limit the definition phase. The more time you give people to think about what should be the project definition, the more the project will be complex. In one IT company, they have a rule that I loved. They say we have six types of projects. Two months project, six months project, nine months project, one year project, and 18 months project. Nothing more than 18 months. And if it’s a two-month project you have one week to think about it. If you’re not getting your conclusion after one week. So the project would be dissolved, and we’ll start in our notes. So limiting the definition phase is very important. For someone what I like is finishing each project within 12 months, even if you’re a big program of three years. Three years is too long a time, you need to have a smaller project. And you need to demonstrate to the business that you can complete this project in a short time frame. I would also like to say, that if you have a very long project, you will never be able to meet its business requirements. Because let’s be frank, if I ask you, what do you need in two years, I’m not sure you really know. And because you don’t know, you want to be on the safe side. So, your answer will be, I need everything. Then the projects are to be complicated. But if I ask you, what do you need in the next three months, or the next six months, you know what you need to do your work better. To get more value from customers or to I discussed. And then we can have a short project that is exactly tailored to your needs. There’re some worries about limiting the project size. That’s an interesting one because very small projects are too costly. After all, in a project, you have a set of costs. Very large projects tend to be off-budget, of delay because they are too complex to manage. So there is the right size. Not too small, not too big. So the trend there works very well there.
In the trend model, if you have too many small projects, you should regroup them into a medium one. And if you have too many big projects, you should cut them into medium ones. There is an optimal size, it depends on your companies and your abilities, but you should be able to find it. Set targets with tangible intermediary milestones. The worse thing in a project is. Every month, people should be able to share project results and advancement. Even if the project is not completed, you can still show something, prototypes, mockups, requirements, understanding. Projects should learn as they go. A good sign of a project is a project where everyone knows, every week and can demonstrate that. Of course, the fifth rule is about prioritizing functionalities. We discussed that in the example. We should be very clear about what are the really essential functionalities, and what are the nice-to-have. This is one very good way to solve the tension between business and IT. I would [INAUDIBLE], if I take a project partly for you, that most of the project, we can have you do if you do good at the 20, we can have you limit size. Many IT shops are afraid to do that, and they feel that it’s beyond their hold. But the only there is to say, if you ask us this, we can do this 50% of the time, or 80%, or 20% of the time. It’s not the role of IT to challenge the business, it is just to provide alternatives. The last point that seems to be extremely of use, establish formal reviews. Everyone knows that the project has to have formal reviews. But I would go a bit beyond that. I have seen many projects with formal reviews where nobody understands what is happening. That’s what I call the classical syndrome of the month from a review where the project is always on time with one month delay every month. And if, what is a good formal review? A good formal review is a form of review where the business people and understand exactly the situation and the difficulties of the project. There must be transparency in the project. The formal review is not something where you want to see all the KPIs in green. You want to seek KPIs as they are. Red, orange, or green, and understand what is not going well and making the right decision. If a business cannot make a decision, either it’s no problem, so the formal review is useless. Finally, the leadership of the project. I have met a lot of project managers. It is tough to find someone who masters both the technological aspect and the leadership aspect and the business aspect. So there are two fundamental roles in the project. The real project manager, or the business leader, would be responsible for the project in the relationship with the business. And they will manage your conflicts between IT and business. And there is mostly a technical project manager, someone who is really managing the project on a day today. They should both work together. They could come from IT, they could come from business, I don’t care. But you should have a team. If you try to apply this rule, you will see that the first story I told you, was not against breaking the rules. It was taking a specific context, a specific project, and apply them in maybe another unorthodox way. But if you understand the context well, and you apply the rule, your project will be successful, even if it feels a bit weird. So I wish you all the best in your project and enjoy them because this is a really fantastic adventure.
