5 mistakes to avoid in Project Management

5 mistakes to avoid in Project Management

Project management has its fundamentals but also its traps. Here are five mistakes that can easily be made in project management.

The project manager can sometimes fall into traps when managing his project.

Whether experienced or junior, some bad reflexes can generate some mistakes. Here are 5 classic mistakes in project management.

Start your project by doing a schedule of tasks

This may seem obvious, but starting a project by creating a task schedule is a mistake. Indeed, before defining tasks, it is good to define what these tasks will be used for. And they will be used to create a product, the product of the project.

The first thing to do is not to define the work to be done, but the product and its deliverables. The first step of a project is therefore to formulate the broad outlines. And we can do that through a project charter, or a project statement. In this phase, we will notably frame our project by clarifying why we do it, and what is expected. This will introduce the work to detail the project product by breaking it into several sub-products or deliverables. And then we can start thinking about the activities.

This sequencing is finally logical : before planning the construction of the walls of a house, I will already make sure that this is a house that is expected and not a garage. Say like that, it's obvious. So I will not open my MSProject or the "Activities" page of a project under Gouti without having previously defined a project charter and deliverables.

Involve users during the validation phase

Involving users during the validation phase is not an error. But to involve them only from the validation phase is an error.

Too often end users are solicited too late in projects. It is from the design phase, including the definition of deliverables that they must be involved. Indeed, it is ultimately they who will validate the product. So it is with them that the deliverables and their acceptance criteria must be defined.

Some will say that it is the customer who validates. Certainly, but the client (if he is not also the user) will ask his end users to check before giving his validation.

Even if you have a list of clear deliverables with acceptance criteria, this will not be enough to guarantee the validation of the deliverables. Because it is the user who will have the last word to validate that the product meets his needs. And therefore, by integrating the user when defining the acceptance criteria, we greatly increase our chances of having the deliverables quickly validated.

Do not plan changes

In the wonderful world of project management I define my project, I realize it, I deliver it. But unfortunately, the wonderful world of project management does not exist.

It is almost certain that during the project, events, new needs, constraints appear and require the integration of changes. This means that, from the start of the project, it is necessary to define the processes that will be used to manage change requests. A change request does not mean a change. A change request is qualified, analyzed, and then a decision is taken. And depending of it, we will integrate or not the change. If you do not put this process in place from the beginning, it will be very difficult to define it during the project because at that moment, you will be in a hurry.

Note that a quick and easy to fill form is available in Gouti for the management of change requests.

Communicate with the detailed schedule

A schedule can quickly become complex. By its multitude of tasks, relationships between tasks, durations, a detailed schedule will become difficult to read. The detailed schedule is first of all the working document of the project manager. For the communication of the planning towards the customer, the user, the manager, it is necessary to be able to synthesize by producing a clear and readable planning: a macro-planning.

This macro-schedule must show the main tasks, the main milestones. If possible, we will make a graphic version that fits on a page. Do not underestimate the impact of miscommunication by a schedule in an overly complex version. A project manager must know how to adapt his communication to his interlocutor. The macro-planning is one of these elements of adaptation. Although graphic, even a GANTT may be unreadable.

For example, a PowerPoint slide may be the answer. You will also find on Gouti a component allowing to automatically create a macro-planning.

Do not do risk management

The risk. Risk management ... Even before we start, we may think that we are going to enter a complicated, cumbersome, administrative process, to see useless. And this may be the case if you do not know how to adapt this process to the size of your project.

I wrote an article on the website of CG Project Management (in french sorry ...) explaining the outline for effective risk management. It is important to understand that a risk management adapted to your project is an important asset for the success of the project. This improves anticipation, communication, decision-making. This risk management is a process that runs throughout the project. The project is evolving, so are the risks.

For starters, you can work with a simple spreadsheet. The important thing is not to work alone on this subject, it is a work that must be done with all the stakeholders of the project. And it will be necessary to regularly repeat risk reviews. Obviously, you will find on Gouti a solution of risk management

-----

Christian Gutekunst