5 Things You Might Not Have Been Told
Today I would not be sharing a tip on how to use a Planning software but instead I am going to make 5 suggestions that I think people starting out in Project Planning might find relevant. These are my personal thoughts and are non-prescriptive principles that have guided me thus far in my Project Planning career.#01: It’s not all about P6
It is so common these days to see job adverts looking a Primavera P6 Planner. These types of job adverts will no doubt lead many new entrants into Project Planning to think that proficiency in P6 is all that is required to become a good Project Planner.
It is 2016 but there are some planning functions that P6 does not implement. Some examples are:
- Hard & Soft Logic Links: The ability to mark a relationship as required (mandatory or hard relationship) or preferential (discretional or soft relationship). Asta Project implements this with their Driving Logic feature. Remember that the 4 Beatles (FS,SS, FF & the mysterious SF) are types of Hard or Soft logic relationships
- Logical Operations: Boolean algebra is fundamental in computing with 2 of the basic logic operations being AND and OR. But Primavera P6 only implements AND logic as all Predecessors or Successors must be true. Spider Project allows you to implement these 2 important logical operations with their Conditional Branching feature
Even though P6 is very popular and seems to be the market leader, this does not mean it is always the best tool for the job. The industry and/or country you find yourself might determine the software in use. E.g.
- UK Building Construction: Asta Project [1]
- Linear Projects (e.g. Road Construction or Onshore Pipeline installation): Tilos [2]
- Russia or Eastern Bloc: Spider Project [3]
- IT Software Development: Microsoft Project
- Small business with little or no IT Budget: A spreadsheet
- Manufacturing: Preactor [4]
#02: Resources are key
I have heard people say, my schedule is not resource loaded so I do not have to worry about resources. There is nothing farther from the truth than this misconception. Even if you are not going to carry out a detailed resource analysis, I believe resources should always play a big part in the schedule development.
My suggestion would be to document your assumptions for availability of people and materials required to deliver each work package in your schedule. And once armed with these, you can go ahead and build a realistic schedule.
I remember seeing a poster about 10 years ago where someone went to the toilet for no.2 business only to realise halfway through that he did not have toilet tissue and the poster caption was around the line “You should never start a project without checking you have all the right resources”.
When building a schedule that is not resource loaded, I usually create custom or activity codes for resources and use a schedule view (or layout) based on these codes. This way, even though my schedule is not resource loaded, I still get to build a realistic schedule based on availability of required resources
#03: Be a toddler again and always ask why
When my colleague, Callum Ross [5] started out in Project Planning, one advice he was given by his Lead Planner was to always ask why. And this is something I would suggest to all budding Project Planners.
By asking the “why” question, you get to know reasons behind a request, information or data and this should arm you and make it possible for you to easily point out errors in schedule basis or assumptions, build more realistic schedules, carryout better analysis and enrich your knowledge about the project.
Aside from the “why” question, I would suggest you should also ask the “how” and “when” questions when building or updating a schedule
- with “how” question, you are asking for more details about what needs to be done to achieve the desired output and
- with “when” question, you are asking for logic relationships information as well as time constraints
Note that by suggesting you ask a lot of questions, I’m not saying you should be rude to people. The tone of your questions, either verbal or email, should be professional so that it comes across that you are seeking more information to provide a better schedule output.
And there will be times when asking questions within your project team might not be enough and you might need to go online and reach out to other Project Planning professionals on Planning Planet, LinkedIn Groups or Project Planning blogs. But before posting questions online, remember that Google is your friend or use a website’s / forum’s search facility to ensure that the question has not been asked in the past. It is a bit annoying when people ask same questions forum members have previously answered.
And it is always nice to say “thank you” when people spare their time to answer your question, this gratitude will encourage them and make them more willing to share their knowledge in in the future.
#04: Record Keeping won’t hurt
One thing I learnt early in my Project Planning career is to log schedule information as much and as often as possible even though the bulk of project records should be the responsibility of the Project's Document Control team.
My suggestion would be to log all schedule related emails you receive by having a good email filing system in your mailbox as these emails might come in handy for referencing in future. Also, it is a good practice to back-up your data on a regular basis either on your company’s file server or on an external hard drive.
Another suggestion is to use spreadsheets to develop simple tracking systems for different aspects of the project such as Scope Change Log, Resource Change Analysis Tracker, Total Float Analysis Tracker, Schedule Risk Log, Schedule Delay Log etc.
Some benefits of logging schedule information are: it helps with project status reporting, shows compliance to planning procedure and provides context during benchmarking & lesson learnt sessions. But key point to note is that these trackers should be simple, easy to update and should not take up your time.
#05: Remember a KISS is important in Reporting
I have this principle that any report that is more than 2 pages long will not get read and so I do my best to summarise my reports and planning outputs to a single page and worst case, push into 2 pages. With reports, I have learnt to keep it simple & stupid (KISS).
Project Managers, Project Directors and other stakeholders are usually so busy that if they have a choice they won’t go through a 35-page schedule or a 10-page weekly planning report. A 1-page summary report or schedule that provides all the key information and data they need, should make them happy and if they ever need the details behind the summary, they know there is an extensive report or a detailed schedule available to them. Give them something they can quickly glance through and refer to while sitting in a meeting.
A good example of a simple report is a dashboard and if you need to include a narrative, would suggest you use bullet points instead of long sentences. Also avoid passing an opinion on progress status and by this I mean instead of saying good or poor progress achieved in a reporting period, just state the progress achieved in line with defined progress measurement metrics and let your Project Managers or Project Directors make the call about good or poor progress.
Conclusion
In this post, I have tried to present suggestions that I think might be beneficial to someone who is new to Project Planning but that notwithstanding, I would like to know what both budding and experienced Planners think about my 5 points. As always, thanks for reading my blog.
This post was originally published on https://www.plannersplace.com/ [6]