These tips and traps from a project management and scheduling expert cover the essence of project scheduling, framing the workday properly and handling out-of-scope requests.
No Dates
When you schedule electronically, you should not enter start of finish dates for tasks. If you use Microsoft Project to simply capture dates and only dates, you may as well use Microsoft Excel instead. With Project, you enter durations and dependencies instead of dates to create a forecast model. The software then calculates start and finish dates by itself, based on those durations and dependencies. A schedule with dependencies knows how to update other tasks automatically and is a dynamic model. We have started to call this the 4D-1D approach to scheduling: Deliverables, Durations, Dependencies and Deadlines, but no Dates. Entering dates on Auto Scheduled tasks leads to rigid schedules with many constraint dates.
Hours per Day Conversion Factor
Before entering any tasks, you have to specify how many work hours equal a workday by using option Hours per Day on the tab Schedule (ribbon File, item Options). Project uses this setting to convert between time units; it is the time unit conversion factor. All durations will be recalculated when you change this option. For example, if Hours per Day is set to eight hours and you enter a duration of five days, Project knows this equals:
8 * 5 = 40 hours
If you then change Hours per Day from eight to seven, Project changes this duration to 5.71 days:
(= 5 * 8 / 7)
If you start with the wrong conversion factor, Project will interpret durations you enter incorrectly, which may result in a schedule that is too low or high in its forecasts.
Tip: There is a workaround to keep the current durations without having to re-enter all durations when you change the Hours per Day setting. Before changing Hours per Day, copy all durations to one of the extra text fields (Text1, for example), then change Hours per Day. Make sure you have task field Type set to Fixed Units for all tasks to ensure that Project does not change resource assignments. Then copy the durations from Text1 back into the Duration field.
Tip! There is an Auto Save option that saves your schedule every so many minutes, which you can select in ribbon File, item Options, tab Save. Trap! Note that each Auto Save wipes out the list of items you can Undo, therefore, you should carefully consider if you want to turn on auto saving (default is off).
Out of Scope
Capture out-of-scope elements in a note on the project summary task (ribbon Format, check Project Summary Task) using the Notes tool (Task ribbon). We recommend paying careful attention to clarifying what is in-scope and out-of-scope to manage the expectations of your client carefully and early in the life of the project. Creating a detailed work breakdown structure (WBS) and list of out-of-scope deliverables with your client’s agreement ensures that you have had a veritable meeting of the minds with the client, the essence of a contract.
Trap! Also, realize that many team members will happily live with a vaguely formulated WBS, and it will not work as a contract for them either. They may choose to fly under the radar and not be accountable.
This content originally appeared in Eric Uyttewaal’s book, Forecast Scheduling with Microsoft Project 2013: Best Practices for Real-World Projects. Learn more on the Project Pro website here.
Have your own tips? Share them with the MPUG community in comments below.
Sam Huffman
Nice article. Everyone that uses Autosave now has the best tip regarding that function and an issue in using it. +1 Eric!
Eric Uyttewaal
Kevin,
You are absolutely right that it is a bit of a challenge to model in years. Here are some of my observations:
1) The reason 12 months is not accurate is because it uses 20 days per month as the default conversion factor (File, Options, Schedule). A more precise number would be 21.75 days per month ((365 – 52 * 2 weekend days) / 12 months) , but decimals are not allowed in this field.
2) The reason 52 weeks does not work for you is not clear to me because it does for me, 52 weeks goes exactly for an entire year (Jan 1 until Dec 29 with Dec 30 + 31 being weekend days. This is an exact hit as far as I am concerned in terms of scheduling.
3) The reason 365 days does not work is because the Duration field in Microsoft Project is in Business Days, whereas you entered 365 days that are calendar days, which creates a difference of about 104 weekend days (= 52 * 2); you should enter 356 – 104 = 261 days (business days), which yields a very good result as well: it is just one day off (task ends at the end of Jan 1st of the next year instead of at the end of Dec 31)
4) 365 edays is scheduled through the weekends and is a good model, but it assumes all weekend days are work days and that you work 24 * 7, so this not a good way to model Work (effort).
I propose you enter 52 weeks or 261 days from now on. I hope this helps.
Eric Uyttewaal
Sam, thanks! Eric