Clarifying the usage of schedule dependencies, constraints & deadlines

While a correctly developed project schedule is a thing of beauty, a poorly created one can be a source of frustration to the project team and risk to the overall project success.

Developing a schedule before spending time to decompose the scope of a project is likely the primary sin of most poor planners, but it is closely followed by the incorrect usage of schedule dependencies, constraints & deadlines.

1. Schedule dependencies represent a logical connection between two discrete activities.  Such relationships should be related to the nature of the activities themselves and NOT to who will perform the tasks or to other such constraints.  The dependencies most commonly provided include:
• Finish-to-Start: the most common causal relationship hence no explanation is necessary for its usage.
• Start-to-Finish: Rarely used but is useful when developing a schedule backwards from a fixed end date.
• Start-to-Start: this represents a true relationship between two activities and has nothing to do with their predecessors.  If I happen to have two tasks that start at the same time because of a predecessor, that is better represented as two finish-to-start relationships (e.g. systems testing & developing documentation can both begin once development is complete, but there is no relationship between systems testing & developing documentation so we wouldn’t want to use a Start-to-Start dependency here).  This dependency is often used with a lag to represent the connection between two activities that run in parallel but cannot start at exactly the same time (e.g. apply the first coat of paint & apply the second coat of paint).  A true Start-to-Start example is a race between two runners where each runner is represented as a separate activity – while they will likely finish at different times, both must start at exactly the same time.
• Finish-to-Finish: this is generally used to represent activities that must complete at the same time so as to not impact their successor activities or one or more of the objectives for the project.  A non-project example of this is the act of preparing food at a restaurant – the chefs must ensure that the main course and garnishes are ready at exactly the same time so that plating can be done without impacting quality.
2. Constraints represent a real-world limitation that prevents an activity from commencing or completing when it normally would (based on project start date or its dependencies).  Constraints are often most misused as the natural inclination for a novice scheduler is to manually set task start dates or end dates.  Valid examples of constraints include resource dependencies (e.g. unavailability of a training room) or external factors (e.g. maintenance blackout periods that would affect certain types of tasks).  Resource or task calendars if supported by a scheduling engine provide an alternative to the use of constraints.  However, with either of these features it is a good idea to document the specific condition that necessitated the use of the constraint or calendar so that if the condition no longer applies at a later point in time, the constraint can be removed resulting in potentially improved schedule performance.
3. Constraints are occasionally used (especially “finish on” or “finish no later than”) where a deadline would work better.  Whereas dependencies and constraints affect scheduling logic and the start or end dates for tasks, deadlines provide a visual indicator to the scheduler that a “real-world” deadline is likely to be missed.  On large schedules while there might be numerous milestones, there may only be a few true deadlines that have to be observed.  To ensure that the planner is aware of the potential negative consequences of a scheduling change, deadlines provide a “soft” means of notification that will not impede tasks from moving freely or the schedule from being optimized.
4. Lags are sometimes skipped in favour of artificial tasks being inserted between two dependent activities.  For example, once I have placed an order with my vendor, a period of time will pass until the equipment has been delivered.  Using a task to represent this procurement & delivery time is incorrect unless the activity is being performed by the project team and additionally this will throw off the calculation of overall project percentage complete.  A better approach is to introduce a lag between the two activities representing the expected number of days or weeks for the procurement & delivery activity.

While I have not tried to provide a comprehensive walkthrough for each of these features, hopefully it clarifies their usage such that the right tool can be used for the right job!

 

 

 

Are your meetings a microcosm of what’s wrong with your project?

Have you ever attended (or worse run) a project meeting in which many attendees did not show up on time, appeared more interested in their smartphones and where the agenda either did not exist or appeared to be totally ignored?  If so, what was the overall health of the project itself?

Organization entropy rarely spontaneously occurs – to paraphrase Brooks in the Mythical Man-Month, “How does a project get to be one year late? One poor meeting at a time!”.  Being a believer in the applicability of the Broken windows theory to organization behavior, once team members and stakeholders witness a systemic lack of discipline and organization in project meetings, this will likely start to affect productivity and the overall quality of their work efforts.

To misquote Gandhi “Be the change you want to see in the organization”.

Start your meetings on time, whether or not all attendees are present.  Recognizing that participants might be rushing from another meeting, try to schedule your meetings to avoid delays from previous meetings – starting at 15 minutes past the hour might be one way to build in some resource buffers.  If a senior stakeholder takes offense at your attempts to enforce punctuality, challenge them by asking whether it is okay if their project deliverables are provided a few weeks late – if they can’t tolerate tardiness on those, why should they be encouraging tardiness in your meetings?  Similarly, if you are running late for a meeting or are not able to attend it, have the courtesy to communicate this in advance to the meeting organizer along with your input on any decisions that were part of the meeting agenda.

Just as you would never execute a project without some plan and some understanding of the overall vision or goals for the project, never initiate a meeting without an understanding of the objectives for the meeting, the topics and timing.  Even if this information is just reflected in the body of the e-mail invitation itself, this demonstrates a commitment to planning that will hopefully spread through osmosis!  Conversely, if you are invited to a project (or any other meeting) without this basic information, challenge the meeting organizer to provide it.  If you blindly accept and attend a meeting without having this information, you are sending the message that your time is not valuable.

Finally, as a meeting organizer, insist on some basic rules of etiquette.  Discouraging chronic interruptors or those participants that appear to be distracted should start to rub off on others.  The former is usually a sign of someone that has never been directly notified of the impacts of their behavior (and hence, takes silence as consent to continue).  The latter might either be a bad habit or an indication that the attendee was not essential for the meeting.  In either case, addressing the situation constructively but firmly is likely to percolate in the minds of the perpetrators as well as those that might be inclined (due to a lack of consequences) to emulate their behaviors.

Disciplined, organized meetings will not guarantee success but chronically poor meetings are usually a leading indicator of challenged projects.

 

 

 

 

 

 

Quantifying risk management benefits

I had written in an earlier article about using the analogy of insurance as a means of convincing senior stakeholders of the merits of project risk management, and I believe that most people academically recognize the value of the knowledge area.  However, it is likely that at some point in your project management career, you might be challenged to provide more tangible evidence of its benefits.

Risk management activities consume resources that a sponsor or stakeholder could argue would be better invested in delivering a project’s scope.  Similarly, team members might question the benefits of participating in the periodic refreshing of the risk register or their involvement in risk response activities.

When dealing with risk management practices, it can be difficult to provide tangible evidence of their value as in many respects they are a hygiene factor – we expect our projects to have predictability relative to committed baselines, and so effort spent in meeting expectations will often be seen as “business as usual” as opposed to something to be recognized and encouraged.

Here are a few methods of demonstrating tangible benefits to help reinforce project risk management perceived value with the decision makers.

1. Include opportunities in the scope of your project risk management activities.  While threat reduction focuses on meeting project expectations, exploiting opportunities could result in an increase in realized project benefits.

2. Use risk register & issue log data to increase institutional knowledge.  While there is often a rush on the part of resource managers to move project managers and team members to their next project, ensure there is sufficient time in your project closeout phase to analyze those issues that had not been identified as risks and incorporate the ones that have a likelihood of recurring into your knowledge bases.  Of course, knowledge that is stored but not used is wasted, but overtime it should be possible to show a reduction in the number of “been there, done that” issues.

3. Measure the overall effort spent on issue management (aka firefighting) activities when compared with overall effort spent on risk management.  Over time, if risk response plans are appropriately executed, you should see a reduction in firefighting effort with roughly the same level of effort being spent on risk management.  Not only will this reflect more “in scope” work productivity on the part of team members, but its a great way to ensure that your risk management practices are not gold-plated.

With project resource constraints being unlikely to ease soon, project management practices will continue to be scrutinized – through opportunity management and effort measurement, you can reduce the odds of the project risk management “baby” being thrown out with the unnecessary process bath water.