PMI Virtual Library

2011 David M. Ciriello

Project Schedule Strategies: Helpful Hints

for Project Managers and Team Members
By David M. Ciriello, MBA, PMP, PMI-SP, CISA, MCTS

Abstract
Managing the project schedule is one of the primary responsibilities of the project manager. All major projects in todays
market require a project schedule that is actively monitored. These ubiquitous documents not only drive the work being
performed by team members, but also serve as the basis for communicating progress or risks to project stakeholders.
Despite this important role, managing a project schedule remains a process shrouded in assumptions, systematic
automation, personal judgment, and a lack of consistent standards. Thus, this article provides the recommended best
practices for creating and managing a project schedule that will help ensure that the executed work minimizes inefficiency
while maximizing the potential to achieve the projects objectives.

roject management is an immense discipline that cuts

across all industries and encompasses many functional
areas; however, there is one critical tool that every
project manager and team member is required to be familiar
with on each and every project: the project schedule.
A project schedules ubiquitous nature renders it a critical
tool for project managers to ensure commitment to the right
objectives, set the appropriate course of action, and quickly
raise issues to stakeholders. When used properly, a project
schedule can be a project managers best friend. Conversely,
failing to understand the important role of a project schedule
and lacking a basic understanding of its application can
expedite the fall of even the most qualified project manager.
Therefore, the recommendations in the following four areas
provide a helpful foundation to creating and managing a
project schedule that will enhance your ability to achieve
success on your project:
1. Re-conceptualizing Your Project Schedule
2. Planning for Your Project Schedule
3. Creating Your Project Schedule
4. Managing Your Project Schedule

Re-conceptualizing Your Project Schedule

What is Your Project Schedule?
This is a simple question but one worth considering before
we start. Your project schedule is a document that details
the expected tasks over the course of time, which when
completed, will result in the desired outcome (product or
service) that the project was created for. Project schedules
come in many shapes and sizes but typically are housed in a
software application. These software tools provide a simple
mechanism used to create individual tasks and link them to
other tasks across time and at the intervals of your choosing
(hours, days, weeks, or months). As actual work progresses,
the electronic project schedule file can be updated to reflect
tasks that have been completed.
On a small project, there is typically one project schedule
owner, often the project manager; however, large projects can
have several separate project schedules that are all parts of
the same project. In this case, there may be a master project
schedule. These plans aggregate the progress of the individual
plans and track overall project progress at a higher level. It is
important to identify, from the start, which project schedule

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 44 of 961

you will have ownership of and what, if any other plans your
plan will interface with. Are you the owner of the only project
schedule active on your project? If so, you will likely be the
gatekeeper of the plan and may have to help secure buy-in
from multiple parties. Youll also likely be required to interact
with resources across the different functional teams, which
will require you to wear different hats at different times, and
youre also likely to be tasked with reporting your progress to
stakeholders. Conversely, you may be the owner of a project
schedule for a sub-project that will feed into a master project
schedule; in this case, you may have a more limited scope but
be required to understand the process of ensuring your plan is
properly reported on by other parties.
This article focuses on the former or a self-contained
project schedule for a single project; however, the
recommendations in this article can be applied to any project
schedule(s) as appropriate. Furthermore, understanding this
dynamic at the outset is the crucial first step in defining what
your project schedule is.
What Your Project Schedule Really Is
Oftentimes a project schedule is referred to as a technical
documentall those dates and numbers surely drive this
perception. It also has a reputation of being a very detailed
document, understood only by the creator or those actually
performing the work.
I strongly caution against allowing this perception to take
hold of your project. Rather, think of your project schedule
as a management communications tool. Although it contains
many details and numbers, make no mistake, it sends one
signal to stakeholders: whether or not your project is on track.
Furthermore, your project schedule is likely to be widely
dispersed, read, nitpicked, and referenced, potentially by every
key resource and stakeholder on the project. This may sound
daunting, but its true.
This is also your chance to shine as a project manager.
Just like any management communications tool, your plan
needs to be easily readable, accurate, and send a clear message.
It also needs to be well-documented and presented fairly, with
all the necessary supporting information.
Another way to conceptualize the usefulness of your
project schedule is to view it as a road map. Would you
give your boss directions to a destination that were unclear,
confusing, or get him or her to the wrong destination? Or,
even worse, get him or her to his or her destination late? If
not, then you shouldnt communicate a project schedule that
would do the same to the project either. Remember, your
project schedule reflects on you and your ability to get the
project to the right objectives on time.

We have now identified what your project schedule

really is: A management communications tool that guides the
project to its appropriate destination, step by step, and on
schedule, per the project requirements
Understanding Your Project Schedules Audience
Similarly, dont make the mistake and assume that executive
stakeholders are merely high level in mindset. They may
very well review every line of the plan and ask very specific
questions and may have also started their careers in the
project management world, where they served as business
analysts or technical specialists at one point and be intimately
familiar with the work in your plan. Thus, like your resume
or any other management communications tool, information
in your project schedule must be accurate at all times, and the
validity of your entire project schedule may be questioned due
to minor inaccuracies.
Planning for Your Project Schedule
A Guide to the Project Management Body of Knowledge
(PMBOK Guide)Fourth Edition, discusses how the
creation of project schedules should be guided by relevant
organizational standards (Project Management Institute,
2008, p. 130). This is the crucial first step for anyone involved
in owning and updating project schedules.
Your organization may have internal policies or
procedures that provide answers to some of the questions
that exist when initiating your project schedule. The scopes
of these policies will vary across organizations, but where
they exist it is essential to review them in detail. Specific
guidelines may provide guidance or set requirements on
topics such as:
The Project Management Information System (PMIS)
used by your company.
The approval process for creating a project schedule.
The naming convention that is required when saving or
publishing project schedules.
The change management process for updating existing
project schedules.
Following are the crucial benefits to reviewing these
policies:
You will ensure that your project schedule is compliant
with internal policies, which will directly increase its
chances for approval.
Provide quick answers to many of the assumptions that
would exist if you were starting from scratch and allow
you to maximize crucial planning time.
Serve as an excellent foundation for other parts of your

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

2

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 45 of 961

analysis. When reviewing these considerations, you will

frame responses to other decisions not specifically covered
in the policy.
You will gain a better understanding of how your specific
project schedule relates back to your organizations business
processes and approach to project management.
Every organization functions differently with regard to
project management, and understanding these intricacies is
the best start to creating a successful project schedule.
Another helpful planning area, referenced in the
PMBOK GuideFourth Edition, is templates (Project
Management Institute, 2008, p. 32). Although not
always required, it is helpful to review any templates your
organization may provide. When doing so, look for specific
information such as configured options within the PMIS,
suggested task types, font and text, the level of detail of task
names, any metrics used to track variances, and other general
characteristics. It is also a good practice to review several
templates and identify characteristics that are common across
the templates. This will provide a range of options to consider
when creating your project schedule.
Planning for the Expected
Many project managers go to great lengths to identify hidden
risks but sometimes it is the obvious risks that fall through
the cracks. When including your project schedule deadlines
and critical dates, there is one constant that can be counted
on across all projects: personal time; however, this ubiquitous
factor is more serious than it originally appears.
First, be sure to visit your organizations human resources
website to verify the actual holidays for the coming year
and ensure there is no work scheduled to occur on these
dates in your plan. Although basic, this simple step is often
overlooked and can lead to an embarrassing conversation with
stakeholders.
Second, take a deeper look at the time that can be
reasonably expected to impact your schedule. What about
vacations? If you have a team of 10 or more, its a sure bet
that you will get several requests for time off during the
summer. Thus, a good strategy is to approach your team as
early as possible in the planning process to determine who
has set plans and attempt to ensure adequate coverage at all
times. It is also important to refer to your communication
protocols with the client or your boss to verify how much
advance notice they require for time away. If its an external
project, does your client have the same vacation calendar?
If not, can you continue to work if they are not onsite? And
were you able to identify the time off required by third parties

and/or contractors? And, remember, if you decide to assign

resources, be prepared to make detailed re-assignments, which
may impact deadlines if these absences were not built into the
original schedule.
Lastly, what other unique considerations can impact
your schedule? Are there religious holidays that will impact
your team? Does your company or client have required
training that will impact your team? It is a good practice to
communicate with your team and ensure that, when time
away is identified, there is a plan in place that can justify the
viability of your project schedule dates.
Resource Considerations
When designing your project schedule, there is one decision,
which can quickly double the effort and time required of the
plan owner: the decision to assign resources to your tasks.
Project schedules that become resource loaded (resources
assigned or linked to each individual task) require much more
effort to update and maintain. This is because your PMIS will
have built-in logic to flag tasks and resources that are overallocated and may even prevent assigning a task altogether.
Managing these considerations can become burdensome.
Although each project manager will have to decide for him
or herself on the need to include resources, there are key
considerations that can help frame this decision.
First, are their contractual issues at stake? If you are a
contractor, does your client require timesheets from your
team? If it is an internal project, are team members charging
their time to your project code when completing their
timesheets? If either of these is the case, or if stakeholders have
a specific interest in the time spent, assigning resources may
be a helpful approach. In this situation, synchronizing project
progress with timesheets can save time and ensure detailed
cost reporting; however, if you are working on a fixed-price
contract or on a project more focused on deliverables than
costs, you may have more flexibility. Here, tracking resource
availability may be simpler if done separately from the plan.
Second, do you have a resource manager or someone
skilled in understanding the specific job functions involved in
the project? This is important, because incorrectly assigning
resources to tasks may impact project plan dates. If there is
no resource manager, it is a good approach to review in detail
the resources available and the specific expected roles before
deciding to assign resources. Similarly, do you have a resource
on your team familiar with the PMIS your project is using?
Again, if not, it would be wise to consider the level of effort
required to track and report on assigned resources.
Third, what type of work is being performed? If it is
a complex project with many roles, it is a good practice

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

3

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 46 of 961

to identify resource classes. For example, if you identify

classes such as developer, business analyst, QA analyst, and
management you can have the option of assigning generic
resources to the tasks associated with these roles. For instance,
if Task A is to write code for web interface, in your project
schedule, you can assign the general class of developer to
this task. This will provide greater flexibility than assigning a
specific individual to the task. Conversely, if you have a team
with one key skill set or resources who can perform multiple
roles, you may have more flexibility in assigning resources,
which could make a resource-loaded plan more viable.
Creating Your Project Schedule
Identifying Your Deliverables
Your deliverables are the essence of your project and are the
reason for its existence, whether it is an internal or consulting
project; hence, they should be the driving forces of the project
schedule creation. It is important to read the project initiation
materials and understand in detail what the deliverables
include in terms of specific activities and the key dates by
when the team is required to deliver them. Once this is
complete, you have a great start to the cores of both the body
of your project schedule and the date parameters.
It is also important to note that these deliverables should
be easily identifiable within your project schedule, whether
it is being viewed in soft copy on a computer or printed out
and reviewed on hard copy. This can include capitalizing
the deliverable task names, using bold text, or even naming
your tasks as deliverables. One example of how to call out
deliverables via the task name includes:
Phase 1: Execute Project Work
Deliverable I: Quarterly Risk Assessment (Q1)

Sub-task A

Sub-task B

Sub-task C

Sub-task D
Deliverable 2: Quarterly Risk Assessment (Q2)

Sub-task A

Sub-task B

Sub-task C

Sub-task D
Deliverable 3: Mid-Year Executive Review

Sub-task A

Sub-task B

Sub-task C

Sub-task D

Determining the Task Structure

Once the deliverables have been identified, it is helpful to next
map out your task structure before adding any date, duration,
or dependency information. This step can be referred to as an
activities list or viewed as just an early draft of your plan. This
can be done either in Microsoft Word or Excel, on paper, or
within your PMIS by adding tasks names, but not dates or
durations. Visualizing the plan in this manner will allow you
to easily structure, organize, and interchange the tasks based
on how you need them to logically occur. If you try to move
tasks once they have been linked via your PMIS, it will be
much more challenging to make the changes.
Hence, by starting with your deliverables, and
understanding the work that precedes, supports, and follows
their completion, you can begin to identify all of the activities
the project entails. In doing this identification exercise, it is
also helpful to identify both summary activities and the subtasks within them. This basic structure will be a key element
of the final work plan.
Please refer to the continuation of our generic example
below for a common approach to documenting summary
tasks (shown in bold text) and sub-tasks:
Summary Task Structure - Example 1:
Deliverable I: Quarterly Risk Assessment (Q1)
Risk Rating

Review Risk Log

Identify Open Risks

Assess Risk Probability

Assess Risk Severity

Complete Open Risk Matrix
Executive Review
Review Open Risk Matrix with Stakeholders

Secure Sign-off of Open Risk Matrix

Its important to note that this structure is flexible.

Depending on the requirements of your stakeholders, you can
add more summary tasks or additional sub-tasks as needed.
This is one area in which your discretion as a project manager
will heavily impact the finished product of your plan. For
instance, revisiting Example 1 with the goal of adding more
detail, an alternative version would be:
Summary Task Structure - Example 2:
Deliverable I: Quarterly Risk Assessment (Q1)
Risk Rating

Review Risk Log

Identify Open Risks

Assess Risk Probability

Assess Risk Severity
Team Review

Meet with Project Team Members

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

4

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 47 of 961


Aggregate Risk Ratings

Review with Team Members

Finalize Risk Severity
Risk Matrix

Complete Open Risk Matrix
Executive Review
Review Open Risk Matrix with Stakeholders

Attend Stakeholder 1 Meeting

Attend Stakeholder 2 Meeting

Attend Stakeholder 3 Meeting

Update Open Risk Matrix with Feedback

Review Updated Open Risk Matrix with

Stakeholders

Secure Sign-off of Open Risk Matrix

This example shows several additional summary and

sub-tasks that were not included in Example 1; however, this
does not mean these tasks would not have been performed
in Example 1, just that they were not specifically delineated
in the project schedule. They may have been assumed to be
completed within the tasks listed in Example 1. Finding the
right balance of which tasks to include is an important key
to ensuring your plan is detailed, but also manageable and
not overly detailed. Understanding the requirements of your
team, based on the project authorization documents and
listing them using the summary and sub-task distinctions will
help you find the right level of detail for your plan.
Identifying Key Task Dependencies
Using this task structure, you can begin to identify specific
dependencies between the tasks. A dependency means a
specific task cannot start or, in some cases, finish, unless
a prior task starts or finishes. For example, lets work with
the summary task from Deliverable 1: Quarterly Risk
Assessment (Q1) from above called:Secure Sign-off of Open
Risk Matrix. Logically speaking, you cannot secure approval
of a deliverable without first actually completing the work!
Thus, the Secure Sign-off of Open Risk Matrix task cannot be
completed unless the development tasks both start and finish
and is thus dependent on these tasks.
This is the core logic of any PMIS and is critical, because
in your PMIS youll need to link or connect these tasks to
each other. This allows the PMIS to know the sign-off is
dependent on the completion of the work, and thus if the
work is delayed, the impact of this lateness will be shown to
impact the start date of the sign-off. In other words, if you
update the development tasks to be 10 days late, the sign-off,
because of its link to the development tasks, will automatically
be shown to also be delayed by 10 days.
As you can see, this is a great benefit in that this
automatic functionality allows you to understand the impact

of work delays and see how the tasks throughout your plan
are inter-connected; however, it is crucial to input all relevant
task dependencies. If a key dependency between tasks is not
included in the PMIS, you may be accidentally showing more
progress than you actually have. With this understanding,
you can leverage the task structure and your list of activities
from above and add to it the key dependencies based on your
understanding of the activities and their key dates.
Duration Decisions
Another decision that will impact your plan creation is
deciding on the appropriate unit of measure for your
task durations. Within your PMIS youll be required to
determine the duration of each task. Typical units of measure
include minutes, hours, days, and weeks. Selecting this unit
determines the level of detail, and thus effort, in designing
and managing the project schedule. Some professions (e.g.,
lawyers), may need to document their time by the minute for
billing purposes and may require such a level of detail. Other
projects go on for years and include hundreds of resources,
and this unit of measure for duration would be conceptually
and practically impossible to manage.
Following are several factors that are helpful to consider
when selecting your duration unit of measure:
What are the contractual obligations for reporting or
billing your time and what is the fee structure for your
contact or project?
Is your team being compensated by the hour or based on
the work product alone?
What is the duration of your project, and how many
resources do you have?
How many deliverables are there?
What do your stakeholders expect in terms of the level of
detail?
Who is updating and owning the project schedule and
what is his or her skill level with the PMIS?
Considering these factors will enable you to make an
informed decision on your project duration unit of measure.
And, remember: the smaller the unit of measure, the longer
and more complicated your project schedule will be.
Leveraging Your PMIS
Now that you have your key deliverables, a list of all activities,
an understanding of the key dependencies, and your duration
unit of measure you are ready to add the tasks into the PMIS
and assign each task its duration, start, and finish dates.
Having employed the above approach, you are now ready to
leverage the core functionality of the PMIS.

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

5

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 48 of 961

To begin, identify the project start date. By setting the

date of the first task, you set the foundation for all other
tasks. Once you set the date of this first task, you will need
to manage the interaction of the durations, dependencies,
and dates between the tasks you are linking. This needs to be
done for all of the tasks in the plan, until each task is linked
to its predecessor(s) so that the PMIS logic is intact. Although
the mechanics of this may vary based on how your PMIS is
configured, the approach outlined above has provided you
with the information needed to ensure the PMIS reflects your
vision for the plan.
Additionally, there are many options that can be
configured within a PMIS. For instance, you can customize
how the PMIS automation responds to date changes, task
dependencies, and task types that you identify. Although
beyond the scope of this article, as you learn the details
of your PMIS you will also be able to tailor the system to
respond to the specific needs of your project and the level of
detail required by stakeholders. Understanding these options
will be a factor in ensuring you are securing the maximum
benefit from your PMIS.
Managing Your Project Schedule
After you have a project schedule in place, its important
to remember that your plan is not a static document, but
rather a dynamic communication vehicle; therefore, the goal
is to make reporting the information contained within your
plan easy to understand from the perspective of an outside
observer. Following the recommendations below will help
simplify and improve the management and communication of
your plan.
Revisit Your Plan Frequently
In this instance, think of your project schedule as a budget.
Like a budget, your project schedule sets a goal, or an estimate,
of how work will transpire on your project. As we all know,
what actually happens is often not in line with what was
planned; thus, it is important to closely monitor the progress of
your team by reviewing the details of how the project schedule
actuals are being updated in the plan. As work completes, the
team or the project schedule owner, will update the percentage
of the tasks that are complete, but dont make the mistake of
launching a project schedule at the project outset and then
attempt to match progress to this static plan. Things change,
deadlines are missed, and your project schedule needs to be
fluid and reflect the key date or scope changes that impact the
overall progress. Remember, a delay in the early stages of a
project may very well impact every task that follows, based on
the dependencies you have included. Thus, its important to

update the project schedule when such a change occurs, so that

the PMIS can reflect the impact to your dates throughout the
plan based on your dependencies.
Leveraging Policies and Procedures
Now, just because you are monitoring your plan tightly does
not mean you have to reflect on every minor change to a date
or task, and doing so may even be impractical based on how
many users are updating the plan and how much of your
time can be allocated to owning this process. So, determining
at the outset the types of updates requiring foundational
changes to your plan is a good approach. Fortunately, you
can leverage internal policy documents when creating these
parameters. Most companies will have a formal change
management process for updating project schedules or
processing scope changes. Changes to the original scope of
work or delays to key dates may require approval of project
stakeholders; however, minor changes to individual tasks or
non-critical dates may be something you can address on your
own. Referring to formal policies and procedures will provide
answers to many of these questions and ensure your plan is
compliant with internal requirements.
Understanding Whats Important to Stakeholders
Project schedules can often be detailed, confusing, and data
intense; therefore, one of your key goals in terms of reporting
progress is to simplify your plan. The most important
consideration here is to understand exactly what key
stakeholders will be focusing on when reviewing your projects
progress. Are there key dates that cannot be pushed back or
moved? Are their governmental reporting requirements or
key contractual deadlines that cannot be missed? Are there
deliverables that require their review and approval by a certain
date? Identifying these critical elements and reporting on their
status will go a long way in ensuring your plan is acting as an
effective management communications tool. Dont let these
key requirements be buried underneath a mass of data or less
critical dates or tasks.
If youre skilled with your PMIS, you can also investigate
built-in functionality for reporting; here, you may find easily
readable reports that are pre-formatted to provide status
information on your plan. Through an understanding of your
stakeholders key needs, you can likely customize these reports
and implement a process to streamline the reporting of your
plan on a repeatable basis.
Working with Your Project Team
Perhaps the most important area to consider when managing
your project schedule is your team. Project schedules directly

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

6

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 49 of 961

or indirectly speak to all of the work that is ongoing within

the project. Therefore, your team members will implement a
high degree of judgment when reporting on the progress of
their assigned tasks. Here it is important to understand what is
driving their status updates, what is causing them to be ahead
of schedule, or what may have caused them to fall behind.
Was it due to an ill resource who was out?
Are they waiting for information or deliverables from
another team or an external party?
Do they expect these conditions to continue?
The only way to learn this information is to support your
team, listen to their feedback, and ask the right questions
when something doesnt seem right with regard to the data in
your project schedule. Through leveraging the knowledge of
your team and understanding the conditions on the ground,
you will be able to provide additional insight into the project
schedule when interacting with stakeholders. Ultimately, this
will help you to maintain buy-in of your project schedule.
Conclusion
Remember: your project schedule is a communication tool
and perhaps the most important such tool in the entire
project. Understanding this and leveraging the above
recommendations can help ensure your project schedule
becomes an asset to the overall project. But, it is also
important to note that your project schedule is not the end
result, but rather the means toward that end.
The end result is the realization of the projects objectives.
Your project schedule is the process or steps through which this

end result will be achieved; therefore, the above recommendations

will help you manage a project schedule that consistently, clearly,
and precisely communicates your projects current status toward
achieving this result. In doing so, youll be providing stakeholders
with the knowledge required to properly monitor and support their
investment.

References
Project Management Institute (2008). A Guide to the
Project Management Body of Knowledge (PMBOK Guide)
Fourth edition). Newtown Square, PA: Author.

About the Author

David M. Ciriello is a Project Management Professional
(PMP) and Project Management Institute Scheduling
Professional (PMI-SP) credential holder with seven years
of project management and project management office
experience. Mr. Ciriello has supported or led many IT and
business initiatives for executive leadership in the areas of
strategic planning, business analysis, governance, process
improvement, and status reporting.
He is a graduate of Oxford University and works in New
York City, where he provides advisory services to the public sector.
He is an active community volunteer and currently serves on the
board of directors for a New York-based 501(c)(3) not-for-profit
organization. He also serves an Auxiliary Police Officer with
the New York City Police Department. Mr. Ciriello is a member
of the PMI New York City Chapter and can be reached at
david.ciriello@alumni-oxford.com.

PMI Virtual Library | www.PMI.org | 2011 David M. Ciriello

7

Preparado con fines acadmicos por dgar Velasco Rojas, PMP / Versin MAY15

Pgina 50 of 961