Every profession has its own set of requirements. The technical knowledge and competencies are a given, however the soft skills are what distinguishes the outstanding from the just-good-enough professionals.
There might be people who believe a planner should just use the input he/she gets and put it together and deliver the project planning as the output. In this mentality, the planner is just responsible for a good use of planning software, and not the input. But as the saying goes: garbage in, garbage out! In this regard, one might think being a planner is a great job! You do your part and can blame any shortcomings on the input provider. This mentality makes the planner just a software technician and in no way a project controller. In reality, the planner is responsible for the input, just as much as he/she is responsible for the output.
This certainly does not mean that the project planner should be aware of all the technical details of the project (as someone who recently changed industry sectors, I myself am a living example of this!), however two instruments are needed: logical thinking and an active/assertive personality.
As I already mentioned in my last article, the project schedule is one of the main stages that the logical link between the design and the execution are put to test. Based on the project schedule, one can oversee the potential pitfalls of the execution, which in the engineering phase might have slipped through; think about resource and workspace availability, accessibility of the site, logical order of the activities and etc. It is actually the middle step between theory (design) and the practice (execution), as a result it is important for the planner to be able to rationally connect these two together.
On the other hand logical thinking can only be triggered by the right assumptions. In the case of a project, these assumptions are the input that the planner collects. But as already mentioned, the planner is not expected to know the technical details of every component in the project to be able to assess the quality of the input, however he/she is expected to be a good data collector and analyzer. A good data collector/analyzer will not only gather any relevant piece of information that is available, but will come up with a method to put the information to test, therefore increasing the reliability of the data. To do so, consulting the expert (engineer, executor, purchaser, resource manager…) is required. One most commonly used method is interviewing. Regardless of whether it is in the form of a casual gathering, phone conversation or a full scale meeting. In this stage, you have to keep in mind that by just asking simple questions, the foundation for your input will be laid down, but by no means are you done. Follow up questions should give you insight on why a certain work method is chosen or for example why activity A is supposed to start before activity B. Try to find the underlying motives, constraints and logics. Remember everyone will provide you information with regard to their own field of expertise, it is your job to connect the dots. And to do so, you need to be able to identify which dots are fixed and which are just misconceptions! So be assertive in your search and don’t blindly accept any input.
By discovering the underlying logics, you will be able to analyze the input much more confidently. Now you can get busy with drawing your first draft of the project schedule. By putting together all the input you have collected, you will be able to see any potential conflicts (whether it concerns meeting the deadlines of deliverables or is regarding the feasibility of work).
In the next step, you are required to find measures that will solve the aforementioned conflicts, or simply mitigation measures to ensure the efficient use of resources. This can be as simple as changing the order of the activities, but can also require more complex solutions, which again entails consulting with the expert. As the first round of information gathering, here the activeness (and assertiveness) of the planner is again important. Explain the problem, introduce your solution and ask for suggestions. If the eventual solution affects inputs provided by others, ensure that they are also engaged in the discussion. Notice that being assertive does not mean forcing your conceived measures, but means actively communicating what your opinions and judgments are, instead of passively waiting for the input to be delivered to you.
Continue this process until the conflicts in the planning are resolved, concerns put forward by others are thoroughly considered, any additional risk caused by the measures are justified and your (and your team’s) confidence in the reliability and efficiency of the planning is satisfactory.
To sum up, be logical and hunt the right inputs down instead of waiting for others to deliver it to you!