Planners' Place

View Original

Junior Planner or Scheduler: 5 Things You Might Not Have Been Told

Here are 5 suggestions I usually give, when I have been asked in the past to advise Junior Planners & Schedulers just starting in project planning and scheduling. These are my 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 for 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:

  1. Hard & Soft Logic Links: The ability to mark a relationship as required (mandatory or hard relationship) or preferential (discretional or soft relationship). PowerProject 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

  2. 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

I see P6 as a tool that enables the application of planning principles to produce the desired outputs, be it a Gantt chart, a resource histogram or s-curves. I believe you need to know what you are doing before you can use it effectively as this will allow you to know the limitations of P6 and think of workarounds to achieve desired outputs.

See this content in the original post

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 in, might determine the software in use. E.g.

  1. UK Building Construction: PowerProject

  2. Linear Projects (e.g. Road Construction or Onshore Pipeline installation): Tilos

  3. Russia or Eastern Bloc: Spider Project

  4. IT Software Development: Microsoft Project

  5. Small business with little or no IT Budget: A spreadsheet

  6. Manufacturing: Preactor

Instead of getting so hung up on P6, my suggestion would be to hone your project planning skills as those skills will always remain relevant but can you say the same about a software? What happens when your company’s corporate IT policy changes and they decide to go for another product? Do not assume the software is always right, remember GIGO (garbage in, garbage out).

#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 the 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 the availability of required resources

#03: Be a toddler again and always ask why

When my colleague, Callum Ross started out in Project Planning, one piece of 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 the 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 the “how” question, you are asking for more details about what needs to be done to achieve the desired output and

  • with the “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 the 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 the future.

#04: Record Keeping won’t hurt

See this content in the original post

One thing I learned 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 reference in the 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 learned sessions. But a 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 learned to keep it simple & straightforward (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.

See this content in the original post