Conni MedinaManaging Editor| Teacher Created MaterialsCa, United States
What are the best practices for using manual dates vs. auto dates in MS Project 2013 schedules. My company is struggling with how to implement this as a protocol. Saving Changes...
Sort By:
Jack BlackChief Project Officer| PMConnectionJackson, Oh, United States
Hi Conni,
I assume you are talking about using the Manually Scheduled task mode versus the Auto Scheduled. I believe there are situations where Manually Scheduled tasks are beneficial. However, in order to get the most out of a dynamic schedule in Microsoft Project, you should use the Auto Scheduled option for all tasks.
Ken BurrellIndependent PMO Professional| Pragmatic PMO LtdLeighton Buzzard, Bedfordshire, United Kingdom
Manual dates are fine if you are happy for your schedule to be a static picture with aspirational dates that you just stick on a wall.
Your schedule will be more useful however if you link all your tasks together using dependencies, and allow MS Project to calculate the dates automatically.
You can update your schedule with actual start and finish dates, forecast delays, etc, and MS-Project will calculate the start and finish of the subsequent tasks in the project.
You can enhance this approach by entering deadline dates for key tasks (probably using the aspirational manual dates you would otherwise have entered), and MS-Project will warn you with a special icon if any of these tasks are delayed beyond their deadline dates.
In this way the schedule becomes a really useful to help you answer the question - "will we get it done in time?"
There are a few tips on custom fields and formulae to make your MS Project schedules more useful in my blog at www.brilliantbaselines.com. Saving Changes...
Allen YoungAccount Executive / Engagement Director| PM SolutionsPa, United States
Having been a Primavera and MS Project SME for many years, along with exposure to many other PPM tools with scheduling engines in them, I agree with the previous respondents that you ideally should let the software calculate the dates. A "manual" date is really a date that is constrained in some way, and the more constraints you apply to a project schedule, the harder it becomes to effectively maintain it, determine resource over/under-allocation, and get the dates to behave the way you want without conflicts.
I tried-and-true way I've always taught people to build a schedule is as follows:
(1) Create a WBS for the project.
(2) Add lower-level activities/tasks to the WBS, with estimated durations, as task-dependent (resource-dependent is for specific circumstances where you are locked-in to specific named resources, or your firm's portfolio management maturity is so good that you have high confidence that the resources you assign are the same resources that were committed during the portfolio planning process--which is rare, by the way!). Use a duration type where the duration is fixed during the planning process...you can always change it to fixed units (typically labor hours) later after named resources are committed and assigned to tasks.
(3) Add dependencies (predecessors/successors). Note the critical path and the project end date calculated by the software (will change as the project moves forward). If you (or management) aren't happy with the end date(s), see if some tasks can be done in parallel, reduce durations (if reasonable), see which tasks can be done faster with more resources, etc. Once you've done that, and there are still some dates that aren't lining-up with expectations, that is the time to consider applying constraints (must finish by, must start no earlier than, etc.). my recommendation is to always apply them SPARINGLY, because once set, you've locked in those tasks.
(4) Assign roles to tasks.
(5) Once named resources have been identified and committed to the project, for the required roles, assign them to tasks. Don't forget non-labor resources, such as materials and equipment.
(6) If you want a fully resource and cost-loaded schedule, make sure the resource pool has labor rates associated with each resource, so the software can calculate the cost.
(7) Baseline the schedule at the intervals acceptable to the organization. Since MS Project allows you to do this at any time, it is best to have a predefined process that spells out when it is permissible to do so (e.g., after requirements; after design; after approved scope changes). Once baselined, that is the schedule you manage to every week or whatever frequency works for your organization.
(8) Apply actuals to the schedule (when work started, when it was completed, labor hours applied to the tasks, etc.). Once you are satisfied that the actuals are correct, reschedule the project (if you aren't allowing the software to do this automatically, then you have to manually initiate it). The difference between the actuals and the baseline is the variance--schedule (time) and cost. If you are interested in doing earned value calculations/graphs, so you can see how the project is trending based on progress made to date, you can't get there without variance.
In my experience, a schedule that is chock full of constrained dates is virtually useless, because it usually reflects the target dates management wants to hit, but doesn't reflect reality, and doesn't allow for the normal ebb and flow of a project where actuals rarely hit the predicted outcomes on the exact dates and spend rate, and where adjusting task durations, assigning additional resources, re-working the sequencing so that more work can be done in parallel is a normal part of managing a project. That's why the Project Management Institute's PMP exam doesn't include a section that tests one's psychic powers--even though management ironically often expects that to be a PM's primary skill. Most projects past a month in duration fluctuate at least to some degree--the larger they are, the more fluctuation--and a schedule loaded with constrained dates doesn't give you the ability to show it. Saving Changes...
Bill BiglerProject Scheduler| Booz Allen HamiltonCentreville, Va, United States
So far, I have found 2 uses for manually scheduled task mode: 1) as contractual deadlines, when I want a separate milestone; and 2) when I am requested to provide a section of a schedule in MS Project.
In the latter case, I highlight all of the tasks requested; change them to manual mode using the Task Mode column; and create a new schedule. That process eliminates issues with the dates changing due to predecessors disappearing.
Otherwise, it is auto scheduling. I hope this helps. Saving Changes...
Kelley Dean-CrowleySr. Project Manager| Major Financial FirmMartinez, Ca, United States
A number of people have responded on the Manual vs. Auto conundrum. My preference is to view the plan as a model of the project. As plans frequently change or are refined over time, auto-scheduling will be a timesaver, as any dates that are changed will reveal problems later on.
Constraints should be done with the constraints item, so that the constraint can be calculated into the plan.
But I notice the other part of the question is how the organization should create a 'protocol' for the Manual vs. Auto question. My answer is that the organization should not create procedures for project managers or even schedule managers to this level of granularity. Project Managers and associated roles tend to be high-functioning individuals that need to be flexible to dynamic needs and states and are fully capable of making this level of decision for their projects.
The organization would be better served by ensuring core competency with dynamic scheduling for its staff..... Saving Changes...
Briefly, I have 2 questions that I think are central to this decision, from past experience
1. Will more than one person be updating the project plan? If there is more than one do they have absolutely identical MS Project versions, plug-ins and level of access?
2. Is your organisation happy to accept working on an auto-scheduled basis? i.e. when MSP advises that Fred needs to make Widget A by the 23rd, will you have to spend ages justifying the date to his supervisor?
