An insider overview of project management

As you certainly know now, my day job is management consultant. If I had to choose one word to summarise it, I would use Projects. Every time there are proper projects in an organisation, some consultants are likely to be around. Consultants are professionals of carrying out projects, because projects are about change. And we all need to change to some extent, as organisations or individuals.

As change is everywhere, projects are everywhere, and consultants are everywhere. And among those consultants, the most emblematic category of them re project managers.

A project manager is a bit like a French Prime Minister : it is a very exposed position, which assumes all the responsibility in case of failure but which has a limited power of decision as the strategic decision makers are in the shadow: the sponsors, the ones providing the funding. The upside of the PM role is to get significant credit when a project is carried out end to end successfully.

What does success mean for a project ? Deliver the pre-defined scope, to the required quality, in time and in budget.

But the definition of failure is much more difficult to determine : has a project failed from the moment that any of this factor has been compromised, e.g if we deliver only 95% of the scope ? Sponsors would say Yes, the project team would say No. And they both have valid reasons to say so.

The major problem is the following : it is impossible to perfectly estimate the resources required in order to deliver a certain scope to a certain degree of quality. An estimation, per definition, recognises the idea that not all the required information was available at the time the estimate was produced, therefore it is non sense that this estimation is perceived as the golden benchmark against which the project performance is assessed on the way. And unless we already burn 30% of the project’s money by having the project team working on a more accurate estimate, the following is an absolute truth :

It is impossible to have a perfect estimate of the resources required to deliver any project.

Usually, a project burns more resources than initially planned because many problems faced on a project are unknown at the time of the planning. The only way we can take them into account is through a buffer called contingency, but estimating the right level of contingency is another difficult question to answer. It is actually the first one that a Project manager has to solve – before the actual start of the project – and he/she will then be committed to deliver the actual project within the resources provided (assuming he obtained what has been requested).

This is why the Project manager role is highly difficult : you may be the one digging your own grave if you are unable to deliver something that you committed to deliver based on the resources you asked for. In order to optimise the chances of success, a project manager better take the most appropriate approach in order to deliver his project.

Various competing approaches to project management or delivery exist and are documented, and I am going to try to present the main ones to you in a nutshell.

 1. Waterfall

Waterfall is the most traditional way of doing project management. Using a top down approach, it is logical to the human mind. What is the waterfall approach ?

1. We plan
2. We analyse
3. We design
4. We build
5. We test
6. We deploy
7. We support

Simple and easy. This approach is called waterfall because the Gantt chart of the Project Plan looks like that :

Now let’s remove the business jargon. Basically, waterfall means : First, I try to think of what I want at the end with all the details possible. Once I have a clear idea of that, we build it. Then we test it, and when we are sure that it is fine, we’re good to go with it. And it can be anything: a house, a painting, a book, a blog post, etc.

Sounds perfect doesn’t it ?

Well not really : just imagine that the project is about a painting a house in a mountain setting. And half way through the build you realise that you actually prefer the house to be next to the sea rather than in the mountain. However, your painter has already drawn the mountain perfectly, with all the details specified in your vision. Sounds difficult to now turn that into a sea…

Therefore, with a waterfall approach, in case of big problem on the way, it is very difficult to find tactical solutions to remediate to it. The dilemma is « should we go for the mountain or should we just scrap the current work and start it again from scratch ? »

That’s why many people in the project management community say that waterfall is bad.

But no, it’s not bad, not at all. It definitely has great advantages, such as :

• It forces you to think about your product first before building it, and clarify your vision
• It is definitely appropriate in situations where re-work is almost impossible, such as the construction industry : Once your house is designed, you just go for it, and there is no way back. Therefore you better spend enough time and money on the design.
• It may save execution resources if the design has actually been done in a neat way due to the very small amount of re-work.

So no, waterfall is not bad at all, it is just not the most appropriate approach in all situations, especially the ones where you may have to change the direction of a project quickly. In those situations, it is more suited to have a more Agile approach.

2. Agile (scrums)

The Agile approach is the absolute reference in the world of software development. Why? Because most software can be configured and reconfigured easily and on an incremental basis. And Agile is all about this: Deliver a product incrementally. Moving forward step-by-step allows the project team to easily change direction or even go backwards, without major negative impact on the project in terms of cost, timing or quality. So, instead of having long planning, analysis, design, build and testing phases, we have a sequence of multiple small cycles of development (=build) and testing, fueled by ongoing analysis and design.

Let me tell you more about Agile. In an Agile framework, the team is not called team but scrum. This is because in a scrum (appreciate the rugby analogy), every team member has a dedicated role, but everybody works together on the same items at the same time in order to ultimately deliver the targeted result (the end product). The scrum works together during cycles of set periods of time (usually two weeks) called sprints, during which they try to deliver a sub-set of the project scope. Ideally, this sub-set is a minimum viable product, which should provide the client with some tangible part of the project’s expected value. The purpose of the minimum viable product is to realise the project benefits on an ongoing basis, and not only at the end of the project, as it would be the case in Waterfall. Therefore, if the project’s sponsors decide to stop the project prior to the end date that was initially planned, they still get some value out of the work performed.

That’s an area where Agile is wonderful: you start the work not when you have a full and comprehensive idea of the end-product, but when you just know enough to get started in order to fulfill a part of the expected outcome.

A sprint works as follows (the timelines may vary from a project to another): 1 day of planning, 9 days of development (=actual work) and test.

You can visualise the benefits: you build your product step-by-step, which means that you don’t take the risk of f***-up the design once and for all. If things need to change, it’s not a big deal, it’s not too late to change it. And that’s how Agile is powerful.

At the end of a sprint, and before moving on to the next one, you want to show to the main stakeholder, the Product Owner (the one to decide what the end product should look like), what his/her current product looks like. If the Product Owner is happy, the scrum cracks on with the next items in the backlog (=list all of the items to be delivered). If the Product owner is not happy, the scrum re-works some items. The concept of backlog is key in agile. The backlog is the list of the incremental items that need to be delivered in order to complete the project. They typically represent 0.5 to 2 days of work for a scrum, and are prioritised in order of importance. The more critical the item, the higher in the backlog it is.

Each item is sized via a storypointing exercise: each item is associated a number of points based on the effort required to deliver this particular item. Points are only a relative measure. After a sprint or two, the scrum has an idea of how many points it can deliver during a sprint (e.g. 60 points delivered per sprint), which allows the chief of the scrum, the scrum master, to assess whether there enough resources available to complete the project. For example, if the full backlog left to be delivered contains c. 180 pts and there are 3 sprints left, then it should be fine to complete the scope of the project. If ever there were 300 pts to deliver but only 3 sprint, the scrum master or project manager better have a conversation with the sponsor in order to reduce the scope of the project or ask for more money to deliver it all.

Agile’s magic is its ability to incorporate change in the middle of a project without giving-up what has been already done. On the contrary, Agile considers change as an opportunity to make the product even better than initially imagined. If ever good ideas pop-up after the start of the project, it can be added to the backlog easily and delivered in due course. A project manager can therefore leverage on the the team’s creative potential by using an agile framework. Even better, the feedback on the interim product can be integrated into the backlog, in order to make the end-product even better than expected initially. Amazing, isn’t it?

However, don’t be mistaken, Agile is not perfect. Or, as for waterfall, it cannot be applied in all situations. For example, you wouldn’t take an agile methodology in order to build your house. Because a house cannot be consistently re-worked: if you build your bathroom on the first floor and then realise that you want it on the ground floor, it would be too late! On the other hand, for software development, if you change your mind about something, your developer just has to change a bit of code, which may takes only a few hours. Worth considering…

My personal view is that the benefits of the Agile approach can be realised much beyond the borders of the world of software development. And I deeply believe that Agile may be well suited for households trying to put their personal projects on track. But more on that point later…

3. Lean

Lean is not an approach of project management per se. Originally, it is more of an industrial approach (the method has been immortalised by Toyota) put in place to make physical products in the most efficient way, i.e. by avoiding waste along the whole supply chain. The underlying in Lean is that a product goes through a pre-defined sequence of activities, and only move from an activity to another when:

• The interim product has been tested and meets the requirements for the relevant activity
• The products ahead have been pushed to the next step as well –it is key to avoid bottlenecks in Lean as building-up inventories takes space and too much inventory is a waste of space.

The Lean approach can be summarised in one tool: Kanban – a Japanese word which means signboard. Basically, a Kanban is a sort of taskboard, divided in columns, with each of them representing one activity of the production process:

I am not an expert in Lean so I won’t spend too much time on it (the more I say, the more I take risk to say some rubbish!), however it is worth noting a few points:

• Lean and Agile are close to each other to some extent, particularly in the way they both divide a product into small pieces. Therefore the two approaches are not completely different from each other (some people try to reconcile both in a Lean Agile approach.
• A key feature of Lean – and it is a primary differentiator vs scrum
  Agile – is that it focuses on continuity, hence the concept of continuous improvement. As Agile operates in short sprint cycles, Lean goes a step further by removing any break in the development cycle: you constantly bring something new into the production line and you improve your processes on the go.
• Lean introduces the concept of limit of the Work in progress. It is forbidden to have more than x (pre-defined) items at a certain stage of the production. They have to leave the process step before bringing more things in (you can imagine here the benefits it could have if such methods could be applied in our personal lives)

4. Common sense

Ok, I admit… I made-up that one, Common sense is not a widely recognised project management approach. However, it doesn’t mean it doesn’t relate to some reality. Look, go on LinkedIn and check all your contacts who put Project Management in their skillset. I can promise you that at least 80% of them believe that their common sense and a bit of experience is sufficient to claim themselves as proficient in project management.

Again, as for the others, Common Sense is not bad per se, and it usually follows the patterns of the Waterfall approach, just a bit more informally: you do a bit of planning, you get started, following more or less the plan, and you follow your own judgement to see whether the result meets the expectations. Well, it works for small projects, the ones too small to justify the costs of external consultants. And it often relies on the dedication of the internal staff assigned to the project, usually on top of their day job, and who are usually torn between the desire to stand-out and the burn-out.

The limitation of Common Sense is when we start to speak about properly funded budgets, with very senior business sponsors, keen to make a strategic change in their organisation. Obviously, in those situations, Common sense does not offer enough guarantees, however, in my experience as a management consultant, I have to admit that I already worked with people with no project management skills, who were trying to rely on Common Sense as a last resort. But to be honest, it usually turns into another approach, very very close to Common Sense…

5. Absolute chaos

This is the Common Sense approach, but badly executed. This is the worst nightmare of a management consultant, and it happens regularly, even in highly renowned institutions. No vision, no plan, no consistency, and in the end: no result, no benefits delivered. Actually, there is one outcome: a de-motivated team, conscious that the work they do on a daily basis goes nowhere. The team members experiencing Absolute chaos usually end-up being disengaged, and many of them just resign.

Here is a visual of a project using the Absolute Chaos :

But here is what the client usually sees:

See below a few tips to recognise if a project you are involved in uses the Absolute chaos approach:

• As I said above, project team members are disengaged. They look frustrated or demotivated and don’t sound as they believe in the value of their project
• Usually, the same people don’t like their project manager
• The team spends more time and effort on project communication, like producing slides over and over again for the client rather than producing output and getting some value for the same client
• Priorities change all the time, even sometimes several time during the same day
• Project Plans are no more than just chevrons and arrows on a page, and have no real meaning whatsoever
• Asking questions is badly perceived (whereas it is usually valued in more normal environments), as if you were suspected of having the intention to destroy the projects rather than contributing to its success
• At 7pm, you are asked to stop what you do and start a presentation (which relates to point 3), which needs to be ready for tomorrow morning (of course), so you stay til 11pm (byebye the birthday dinner with your fiancée) to finish the slides and you are summoned to attend the 8am meeting the day after so that your manager can blame you in front of the client in case your slide doesn’t say what they expect to hear.

Well, you got it, right?

Conclusion: what was the point?

I could speak hours and hours about project management both the theory and my experience of working in various projects. The real purpose of this post is to ask the question on how personal projects could benefit from the approaches described above. And the conclusion is:

• We all agree that we don’t want Absolute Chaos in our household (there is usually enough chaos as it is already!)
• Common Sense is the approach we usually take. But as mentioned earlier, it requires a lot of commitment and dedication, which is difficult to find when we already have a full-time and stressful job.
• Waterfall is what we turned to (without knowing the term) when we are very ambitious about something, But usually, just planning the whole thing makes us dizzy and the size of the whole thing usually makes us believe that we will never have the time and the determination to go to the end. And we stop. (a bit like the Eric Moussambani effect, go check it out!)

What is left? Lean and Agile. Usually those new concepts for people not used to applying the principles in their work places. But when you think of those principles:

Step by step…

Small tasks…

Get started when you know enough…

Obtain some outcomes quickly…

Start with the most important thing first…

Continuously improving…

Changing your mind but still going forward…

It sounds like it may be of interest to whoever wants to make his/her dreams come true, doesn’t it? Maybe the failure in our personal projects is not only a problem of motivation, but just a lack of basic project management skills, whereby anybody could get started with what they want to achieve most in their respective lives? I personally think so…