The goal or goals of a project should be very precisely formulated, and it is worth spending an appropriate amount of time on this task. Just looking at the definition of a project, which says that a project should have an objective to be achieved and a deadline, you can see that the project objective is of fundamental importance. I once worked as a business consultant with a large Polish company that launched an internal process optimization project. One of the optimized processes was the ‘food syrup production process.’ The CEO defined the following objective of this project: “to optimize the syrup production process.” Of course, I wouldn’t say I liked the project objective formulated in this way. I urged the chairman to consider it and try to make this objective more precise. After some thought, the newly formulated objective was “To reduce the cost of the syrup production process by 20%”. It is immediately apparent that such a target is more concrete. Without a doubt, a concrete objective is a signpost for the project team during project planning and implementation. The less well-formulated the project objective, the more vague this signpost is and the more difficult it is for the project to succeed. Clear and precise objectives can significantly reduce the stress and uncertainty for the project team, making them feel more at ease and in control.
The most straightforward tip for formulating a good project objective is to take the time and the desire to make the project objective the best possible. This tip may seem trivial, but there is no way to avoid thinking, and thinking often takes time. It is undoubtedly worthwhile to involve knowledgeable people in developing a project objective – we will have different perspectives, increasing the likelihood of developing a better objective. Sound project management methodologies recommend that large and significant projects have a so-called business case developed. Generally speaking, a project’s business case is a detailed analysis of the project’s rationale, potential effects, etc. Formulating and justifying a good project objective is undoubtedly much easier once such a business case has been developed. I think the justification of the project objective is worth writing down. The Project Charter should include both the project objective and the business case. An example of a Project Charter from a project management program is shown below.
Formulating and specifying the project objective through one or more performance indicators (KPIs) is good practice.
The project objective or objectives form the foundation for designing the project schedule. A well-formulated project objective can be translated into partial and final project deliverables. A very effective method of creating a project schedule is the Product Based Planning method. Only when we have well-described project products is it worth moving on to designing the schedule’s structure of phases, stages, tasks, and milestones. Of course, when building the project schedule, I recommend that the project deliverables be linked to the project phases and that tasks and milestones be defined further within the stages. The illustration shows how project deliverables – circled in red – are linked in FlexiProject to phases, tasks, and milestones.
The project schedule is complete by clearly linking the products to the tasks. Undoubtedly, some project outputs and, thus, some milestones or tasks may be more important than others. Then, it is worth prioritizing them. The illustration below shows an example of prioritizing tasks in the schedule.
Achieving objectives on a project often does not go ‘as planned,’ and the project team has to deal with several problems that arise and manage project risks. Tackling unforeseen issues on a project is precisely identifying and managing project risks. Undoubtedly, the more project risks are identified early enough and dealt with appropriately, the fewer unforeseen problems there will be on the project. The quality of the risk management process is inversely proportional to the number of potential issues on the project. The illustration below shows a project risk register. The project team should maintain and systematically review such a register on a well-managed project. Due to their impact on the project and the high probability of occurrence, significant project risks should be escalated to either the steering committee or the project sponsor.
Monitoring the progress of a project and, thus, achieving its objectives should be systematically analyzed. Tracking the achievement of project objectives is quite often a two-stage process. In practice, we first analyze whether the project has delivered the required objectives at the end of the project. Then, after some time, we analyze whether the business outcomes align with the previously developed business case. At each stage, it is worth making appropriate modifications if this proves to be justified. These are necessary because only some things can always be predicted perfectly at the start of a project.
In summary, well-formulated project objectives are critical to successful project planning, implementation, and completion. Therefore, it is worth doing your diligence to formulate them as well as possible at the beginning of the project and then modify them if necessary.