[MUSIC] I love projects. Projects are 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. Some of the project I've done, people asking me year after year to with all this. But are there rules to do 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, a 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 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 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 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 train model. As you see in this cartoon the train 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 are able to have a dialogue like that with a business, then making project become much more simple. Instead of having something very complex, you have something you can break down in 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 flexibility to cope with the things that will happen during the project. Because there are always something happening, a technical issues. That's hardly the case, but it can happen. An issue with governance, 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 type of project. 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 project would be dissolve, 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 smaller project. And you need to demonstrate the business that you are able to complete this project in a short time frame. I would also like to say, that if you have a project that is very long, 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 in 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 project are too costly because in a project you have set of costs. Very large project tend to be off budget, of delay because they are too complex to manage. So there is a 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 project, 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 the 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 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 into what are the functionalities that are really essential, 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 part 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. Last point 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 project with formal reviews where nobody understand 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 business cannot make decision, either it's not problem, so formal review is useless. Finally, leadership of the project. I have met a lot of project managers. It is very hard to find someone who masters both of 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 most a technical project manager, someone who is really managing the project on a day to day. 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 into your project, and enjoys them because this is really fantastic adventures.
