In my last blog article I covered the concept of Matrix Management and how it can be accommodated and supported in Project Server, the article was compiled as a result of a request from a customer on one of the training courses I was running. I am forever learning about Microsoft Project and Project Server and a lot of the triggers for learning arise from questions or observations raised by people on the courses that I run.
I recently was confronted with a situation where a customer had some tasks that could only happen on the last Friday of the month and other tasks that could happen during normal working time apart from the last Friday of the month, they asked how could this be scheduled using Microsoft Project? Whilst this was a fairly unusual requirement I was pretty sure it would be easy to achieve.
Task Calendars as a feature have been available for quite a while now and are a great way to model “exceptions” to the normal working week. When configuring Project Server for clients we always determine both what their “contracted hours” of operation are and also what statutory holidays they observe.
Contracted hours are important here, what hours should you be working rather than what hours do you find yourself working? All too often people find themselves working excessive hours due to poor planning and end up working reactively which is never efficient or enjoyable. I worked with a customer who was insistent on setting a 50 hour week as their standard because that was what they regularly did, I tried to argue that this was probably inappropriate for normal contracted employees – as always there are exceptions and I have worked with customers in the Oil and Gas sectors where workers will routinely do 12 hour days, but for most traditional enterprises observing hours close to those that are the default for Microsoft Project is good policy.
We also suggest that if you are deploying Project Server across multiple territories that you have a standard working day and week regardless of where in the world projects are undertaken, this can avoid some weird results occurring where people who work in one territory work on projects domiciled in a different territory. Project Server can be invested with as many calendars as you wish to model different territories and their specific statutory non-working days but we would always suggest that they have common underpinnings in terms of hours per day/week and default start and end times.
If you have projects where you “chase the sun” in effect passing work from one person to another around the globe and achieving 3 days’ work in a 24 hour window of time you would need to define calendars where the start and end times are aligned to a common standard such as GMT London so whilst a person in Korea might work standard office hours in that country the Korea Calendar could be configured to show them working at times based upon GMT in London. The problem with an environment like this is that there will inevitably be people who work early or late in order to be able to liaise with colleagues in other Time-zones.
It should be noted that whilst you can have as many Enterprise Calendars as you might wish to have Enterprise Resources can have only one “Base Calendar”, at present there is no option to allow a different “Base Calendar” depending upon the project which the resource is working in, this feature makes observing common working hours the sensible option. Perhaps this feature will be made available in a future release of Microsoft Project Server? Perhaps along with making certain calendars only available to certain audiences in a similar way to how Departments as a feature can be used.
We also assist Project Server customers by creating several Enterprise Calendars that can allow them to schedule exceptions, weekend operations, 6 Day Week and 7 Day Week being typical additions to the list of available Enterprise Calendars – each of these new Enterprise Calendars will mirror the “Contracted Working Hours” for the organisation and will allow some tasks to be scheduled outside of typical operating hours.
Anyhow, back to Task Calendars. I have known some users who insist upon applying the “Standard” calendar, the “Base Calendar” for their project as the option in the Task Calendar drop list rather than the default “None” option for every single task in their project – one person even demonstrated how smart they were by using the “Replace” (CTRL+H – I like to make use of Keyboard shortcuts) option to replace “None” with “Standard” on every task in their project. This approach is in essence stating the obvious and represents a duplication of effort for no benefit – thinking about it why can’t Microsoft engineer things in such a way that the “Base Calendar” for a Project is automatically excluded from the drop down list when it comes to Task Calendars?
Task Calendars can be employed to “bend the rules” on occasions, either because of practical considerations – taking your Mail Server out of action to upgrade software during normal working hours would probably not be a wise move, better to schedule this over a weekend when it would not impact normal operations. Alternately you may be up against a deadline and working a 6 or even 7 day week on some tasks on the critical path would be one way of recovering lost time and achieving the deadline.
These scenarios are quite simple and creating Enterprise Calendars to model such requirements is pretty simple. Creating a Calendar where only one day per month is a working day is however a bit more tricky, thankfully I was able to canvass the wisdom of other Project Server experts and learnt something useful as a result.
To create an Enterprise Calendar where only the last Friday of the month is a working day requires the following actions. In Project Web App you will need to have permission to access Server Settings, from there you need to select Enterprise Calendars from within the Enterprise Data section.
From the Enterprise Calendars page it is suggested you make a copy of an Existing Enterprise Calendar as this will already observe the “Contracted Hours” of your organisation.
The trick in this is to define the Monthly exception before the weekly exception as if you have multiple exceptions on the same day the priority is for daily exceptions, then monthly exceptions, then weekly exceptions – this sequence is not hierarchical and so not immediately obvious as a solution. I am indebted to Sai Prasad, PMP, PMI-SP, MCTS, MVP of Cognizant Technology Solutions who pointed me in the direction of achieving this resolution to the conundrum presented to me.
When using Task Calendars I would always recommend that you ensure that they are applied to tasks where the task duration is equal to or less than the window of time permitted by the calendar assigned to the task, if you don’t observe this simple rule things like the following can be encountered.
Here a two day task with the Last Friday working calendar is shown spanning a greater window of time that a two week task as the two day task can only be performed on the last Friday in April AND the last Friday in May.
One more thing to be aware of when using Task Calendars is that if you apply an “exception calendar” to a task and the task has predecessors with lag values the calendar is applied to BOTH the duration of the task itself and also the duration of any lag period on any predecessor dependency, this can cause real problems for the unawares.