Transcripts
1. Introduction: Hi, I'm Matt Corroboy, a Software Projects Director in the Life Science Industry. I lead a team of project and
program managers delivering software and system solutions amounting to billions
of dollars of revenue. I've always loved
solving problems, creating structure and
removing friction, and working with people and
this has ultimately led me to a rewarding 20-year career in the project management field. Today's class is going to be a deep dive into some
of the key tactics that I've found work best for both scheduling and
tracking on projects. In most cases here, I'm
going to assume that you already know how to
gather requirements, how to create worklists and
work breakdown structures. As a result of that, we're
going to jump straight in and I'm going to
talk about each tactic, what you might need to
do in order to apply it, and then talk about the
benefits that you'll get. For scheduling,
we're going to cover the choosing of the
right task size, the refining the right tasks, and how to build in milestones
and goals that will align and get
through the benefit through the course
of the project. For tracking, we will learn, how we track to the
task size itself, how we monitor the
critical path, and the importance of keeping a change log and
narrative as you go. We're going to wrap all of
this up by talking about scheduling and building
plans that help keep focus and pull the
milestone no matter what project methodology
you might be following. The class project prop list
is going to be a simple one. It's going to be your
project or maybe a typical one in your
organization and I'm going to be asking
if these tactics are already being applied
and whether there's an opportunity for you
to start using them now in order to have
immediate benefit. As always, I want you to
share your progress in the project gallery
itself and ask any questions that you might have on the discussion boards. So let's jump into lesson
one now on some of the key tactics when it comes
to scheduling on projects.
2. Scheduling Tactics: We're going to jump
straight in now to some key tactics that I've
found enable the creation and use of a project plan
to make it more than just an upfront schedule that
people soon forget about. I'm going to be using an
example to explain this tactic, but I want you to think
about your own project, think about your schedules, and how they're
currently constructed. Ask yourself throughout
whether you are getting maximum volume today
out of that plan. Tactic Number 1 is get the
task size right for you. If you think about it, any
work or task can literally be broken down into activities to the minute if you
really wanted to. Likewise, you could leave the
tasks at super high level, for example, build house, but neither of these
allow you to serve the right purpose of having a meaningful schedule or plan. Day-to-day tracking for example, on a two-year
project will likely just create
significant overhead, busy work, and making
you feel like you're doing things but not
really adding any value. Creation of a monster schedule with incredible amounts
of detail in it, will ultimately serve no one. It will be hard to describe,
impossible to track, and more importantly,
just end up being one of those things that's out of
date as soon as it starts. On the opposite end of this, keeping far too high of
a level means that you aren't able to track progress as things are moving forward. You're not able to manage
critical activities, maybe drive to milestones or just communicate
things very easily. This is why it's really
important to get the task size right for you. Think about your project, think about the duration of it, the number of people involved, the frequency maybe
of key milestones or events that tell you that
things are on track, and then think about
what the right size, average task is going to be, to enable you to manage
the project well. Let's use a couple
of examples here, using a tool such as monday.com to create a fairly
basic schedule. Let's imagine it's a
year-long project. There's 10 people in your office working on the project itself, and you're pitching things
at daily task size. That's up to 50 tasks a week, and you might end up then with
schedule where you've got lots of very detailed
tasks that actually, a lot of description of the task might not be easy to understand, and it might be really confusing as to what's happening where. Alternatively, you might want to create
your task level at the week level or the two-week level as a result of that, the task descriptions
themselves can be a little bit more
understandable, little more easy to
share with other people, maybe senior stakeholders, and also keep people a
little bit more focused on outcomes rather than very
tactical things within them. The result here, is
that you're going to be creating teams that are
probably more autonomous. You're not going to be
checking in with them every five minutes in order
to manage that project. Whereas if you're
managing things at the daily task level on
a year-long project, you really almost spoon-feeding activities on an ongoing
basis to that team. You're not really
creating autonomy in the group itself and you're going to be
spending a lot of time managing the schedule itself, rather than actually managing other activities as
part of the project. However, for another example, it might be that
you've just been given a three-week project plan to implement an office move
within the building. This is likely going
to be a schedule with lots of activities
and moving parts and staying close to progress
in the work being done on a daily basis is going
to be absolutely key. It's going to be
fast-paced, it's going to be dynamic and adjustments to the schedule are
likely going to be needed as things go on. In this case, keeping it at
the daily task size level or even a half-day
level is going to be potentially vital to
keep everyone focused. A word of warning here though, just because of
what we discussed, don't make all of your tasks
one week long for example. Because that just
results in some tasks that might be a couple of days themselves being assigned at the one-week level and
costed at that level, so think about maybe just
grouping these together, or in the worst-case,
just keeping them at two days themselves. Sometimes you can't
force-fit your tasks, otherwise you risk it all
just being meaningless, again, which is definitely
not what we want. Tactic 2, focus on high-risk items for
more detailed analysis. One of the key benefits
of spending time creating a plan and a
schedule for your project, is to help identify
where the key risk is. This could be in the form
of a key integration point, or maybe a hand-off
between two groups, or it could just be a difficult
or challenging task that provides a little
bit of uncertainty when we're putting
the plan together. In all these cases, it can make sense to do a little bit
of further analysis, to further break down
the problem into chunks. The reason for this is to
help identify which part of which task actually holds
the majority of the risk. This will allow
then you to look at specific mitigation points and closer management of that task
in order to be successful. Example here, three tasks, Task B makes us feel a
little bit more nervous, a little bit of risk around
it, we break it down, it's actually a
sub-task of Task B, that really holds
a lot of the risk. We can then focus on mitigating
that specific issue, our specific activity
as things move forward. If we take our IT
project, for example, we talked about this
three-week office move. It could be that there's a specific risk that we've identified around the
service coming back online. But actually breaking
that task down into specific pieces shows that there maybe two different
areas where the risk lives. It could be something
to do with cabling being right and connected, and the second piece
might be something to do with having the
appropriate support and personnel on-site at the point when you switch
the servers back on again, in order to mitigate any
risks with coming online. Only by breaking the task down into those specific areas, can you actually see where
some of that risk is. Another good example might be an organizational change
within your business where you've got this
high-level task which is to communicate the key
organizational change. There might be sub-tasks
associated with that, but actually breaking that down, you actually see that there's a specific time-sensitive
group communication that actually breaks down even further to a
specific person, a specific stakeholder in your organization
where you want to put very clear risk mitigation in place and task management
around that person. Only by breaking it down further into much
smaller chunks, we'd be able to understand the specifics of
managing that risk. Tactic Number 3, putting events, goals or milestones
into your plan that will help align the
project moving forward. Let's get back to a
monday.com example here. Think about a schedule
where you've got never-ending tasks right
till the end of the project. This can pose problems in both our understanding
and success as we go, but also in aligning people around the purpose of
what we're doing and why. When creating your
schedule, your work today, think about putting
in key milestones or events that are going
to happen in front of you that's going to signify something significant happening. This might be just that we've changed phases in the project, maybe from ideation
to implementation, or maybe we've met an early goal here, early goal achieved. That gives us some
alignment with stakeholders on a creative
idea, for example. By putting these
in as milestones or goals based on the
work before them, you've got something tangible or outcome-based that can help
drive the work forward. In project teams, this
will really help people to have a short-term
alignment on a goal. Then incentives, rewards, and even celebrations can be tied into these
goals to help keep the focus on the task at hand for a later
win on a project. You can also tie these goals and key events into areas
where there's challenges, things that wouldn't normally be a momentous event for
the project to reach. Let's use an example here
of how we can turn on an event into something that drives that positive behavior. Let's imagine it's
a two-year project in the product
development world, and it's got a lot of
upfront activities around definition of
what's being made. It's complicated, there's
lots of parties involved, there's risk, and there's
lots of opinions. The outcome from all of this is an agreed implementation
plan and scope. Now normally, these
formal approvals mid-project will pass us by and we're all just
relieved to move on. But these events are significant and they signify something
that we should focus on. Making something like
requirements being agreed, a key milestone highlighting it as something
to drive towards. As a result, we help keep more focus and energy on
that goal in front of us, and a clearly worthy target too. This means that
it might have its own tracking associated with it, and then upon hitting
that milestone, we celebrate this event. This can be as simple
as just pausing, bringing in some cake or treats, maybe communicating the
win, thanking everyone, and ultimately setting the tone for how
the project should run from one positive
success to another, building momentum,
creating alignment, and keeping the
energy levels high. So there are three
simple tactics that can make a significant
difference to your scheduling. Before we move into tracking, I want you to spend the time now absorbing what we've
just gone through. Take a look at your own
projects and schedules. Are they pitched to
the right level? Are they accessible? Can you
communicate well with them? Do they describe the project
and its goals easily? Take the time to think
about what changes you might want to make before we
move on to the next lesson, where we'll look at
some of the key tactics when it comes to
tracking our progress.
3. Tracking Your Project Schedule: Once you've got your
tailored size, useful, and meaningful project
schedule in place, then you're off driving
your project forward. But as we discussed, it doesn't stop there, tracking is key. But once again, only if he's telling you what you
really need to know. I'm going to go through
some examples here applicable to each
tactic being discussed. But I want you as we
go through it to think about your own tracking
on your own projects. As we go through this,
what can you change today that will make
you more efficient? The information you react
to more relevant and to help keep everyone focused
around you on what matters. Number 1, get your reporting
tracking period right, don't make worth yourself. This tactic is the twin or the one we discussed during the getting the task size right when we were talking about
creating a schedule. When you think about
tracking your project, you want to create
a system that work specifically for you and
the team around you, one that makes sense
for the project. Repeating status
updates like we've got here in the calendar, where I've got Monday
morning status updates, Tuesday morning status updates, Wednesday morning
status updates, and afternoon updates as well, all you're going to
be doing is spending time interrupting people, adjusting schedules
with percentage of progress being made,
it just won't work. My key tip here is to make the reporting and
task update periods relevant to the average
test size for your project. Really simple rule
of thumb there that really helped me is
that no task should be in progress for more than two reporting
periods or check-ins. For example, if you
set your project with daily tasks, on average, tasks at day long, then think about daily tracking. What would that look like? Tasks are then either scheduled to be done
in the backlog through either in-progress being worked on at the moment,
or they're done. If there's a task, for example, that remains in progress
beyond two check-ins, then a flag should
be raised here that maybe we're not
making the right level of progress on it that we should be and then we can
manage accordingly. If your task size is that the week or two-week
level is average, then shift your cycles
to these timings. Set the expectation of what you're going to be
checking in on them, follow the same in formal rule. You can, of course, still
set the expectation there. Any point a risk or ratio
occurs on any particular task, but that gets
communicated immediately. But at least you're
not spending all your time checking in on progress every single day
other than the project team. Just get on with the work that
they know they need to do. The key here is that you set out your stall early and explain the reasoning for the project. The project teams then
get into the routine. They understand the
flow and purpose and any formal project
status meetings that you might have
in your calendar, they're clear as to what they are for and what
they're measuring. As a result, they can actually
be short and more focused, and people arrived
knowing what he's likely to be asked and what
information you're looking for. The key takeaway
here is to track the level that makes
sense for your project. Don't make work for yourself and don't be
the project manager. There's always
migraine for updates. Create a system that suits the projects and go from there. Tactic number 2, don't sweat the small stuff. Inline with the last topic, it's important not
to overreact to any minor deviations
to the plan. A baseline plan is just that. It's what we said the
efforts and durations would be at that point in time. But projects are
projects for a reason, there are all knowns. New risks, deviations, and
issues that will all occur. Minor shifts that occur
in a plan and expanding in attracting and the task since as they were
set out originally, all just part and part course
of managing a project. The key tip here is to not overreact to the
first slippage that occurs or first task that didn't complete in
it's reporting period. It's natural for these
things to happen. As project managers,
we're always learning. We're gathering feedback on whether the plan is still solid, or might need adjusted, reacting to everything
as if it's a crisis, doesn't really set the
stall out for learning, for problem-solving, and
ultimately for success. Allowing things to happen over a period of time
relative to the project. Build up a picture
then of what's happening ideally with
your core project team, if you have one, and then do
a little bit of analysis. What have we learn? How do we adjust to the plan and the changes that
have just happened? Once again, depending on
the size of the project, then review and analysis could be something
that happens weekly, it could be a monthly
or quarterly. Remember, the
positive leadership isn't reacting all the time. It's been measured, realistic, and clear on approach, and that's the mindset
that will benefit both the project and the team that you might be working with. Tactic number 3, the one thing, critical
path monitoring. Despite everything
we've just said, there is one area where we might want to keep a much closer eye, and be more reactive if
it's user encountered, that area is the critical path. Now there are lots
of flavors and theories around critical
path monitoring. But as a brief summary, the critical path is
a sequence of tasks that all rely on each
other in some way and ultimately dictates
the completion or endpoint of the project
or maybe a milestone. That can be buffer built into these activities to
manage elements of risk. But fundamentally, if any
of these dates change, then it has a direct impact on the endpoint or end date
of the project itself. There are a few
key points around critical path monitoring that are definitely worth sharing. Number 1, make sure
that everyone knows what and who is on
the critical path. Communicate here so much
so that there's clear focus day-to-day on
what's happening there. Two, track or create
direct lines of communication different to
the rest of the project. For example, you
might want to create a more frequent
update period for the current task on
the critical path. This might be a direct line with the individual or
group working on it. This is also that any changes in countered are immediately
communicated. Number 3, have mitigation
plans in place. Be super proactive here. Don't be the project manager
that reports a slippage to the critical paths without any plan or options to respond. Make sure you put plans in
place prior to issues arising. That needs to be on
how any slippages to the critical path will
be managed in advance. That might be an all hands
approach where group people might swarm over a
task to get it done. Well, maybe there's a special
film that needs to be created to deal with some
of those challenges. Tactic number 4, keep a log as you go of any plan changes and any
narrative around them. You spend all your time
developing a plan, setting systems open,
then off you go. But one way later
something happens and things change and
the plan evolves. To be a good project manager, you need to be a realist. You need to know that the
inevitable will happen, but also know that any point
in time someone might ask, what happened to so-and-so
and who decided that? It's important therefore,
to keep a log of any changes that might
occur to the schedule. This can be task
delivered early, task delivered late
maybe, scope changes, resource changes, maybe the movement of a
goal for the project, or it could be a contract
issue with the supplier. Just make a simple note
and something like this, capture the change, adjust the plan
accordingly and move on. This doesn't need
to be complicated. But these notes won't pay dividends when it comes to the right time in
their projects. I've been in countless
projects where people can't remember
what happened, what happened last year, and why we didn't launch on the date we originally planned? What we can do here is we
can filter on things like schedule changes
in the project and immediately see what happened
at that point in time. We can see the people involved, we can see the decision
that was made, and whether there was ineffective rebase lining of the plan all to
everyone's approval. Keeping a log as you track the project will always
give you something to fall back on when those
tricky questions come up. Results are not just
for self-preservation, having a lot of
changes also allows us to look back at the
end of the project and capture some really good
lessons and intelligence to move forward and communicate
for the next project. By keeping the data and applying it to your
next piece of work, you are able to be
a better planner, see a fairly risks, and also justify
why you might have structured something
in a certain way. All in all, it's a really professional
thing for a PM to do. This rarely done by most. It doesn't take much,
but take the time, keep on journaling
and see the benefits. Now that we've been through
some key tracking tactics, it's time once more for you to take a look at your
own approach to this. Where are you over focusing
or maybe not focusing at all? Do you have critical path
visibility or maybe you're just nudging the projects
along with two tighter grip? Take a look now before we tie everything together and we look at different methodologies when it comes to project management.
4. Bringing Scheduling & Tracking to Life: The world moves fast. Techniques and
methodologies change, as well as the language we might use to describe our world. We all have to change and
incorporate best practice here. Whether it's the use
of backlogs, sprints, Kanban or foreign Gantt
chart within value metrics, these are all great tools. But experience tells me that
the best solution is to treat all of these as just not they're tools in your toolbox, to then pick what tool
or approach works for the job you've been asked to do for the project that
you're working on. Often the best solution
might be a blending or a hybrid of many
different approaches. I'm going to talk about
some examples here in this final lesson that
I will share with us. I want you to think
as we go through. This is where you can create the perfect blend
from our toolbox that will give you and your
project that early benefit. Number 1, big picture schedule versus
day-to-day tracking. In certain methodologies,
there might be extremes there, for example, everything is intuitive and there's no
long-term planning in place, while the alternative being
that everything is part of a detailed plan and there's no flexibility in the
way you approach things. Experience shows me that in order for your projects
to be successful, then you probably need both. Here we've got a high-level
Gantt chart view which is shown in monday.com. This is really good for showing the flow of phases representing longer-term goals
and how we enable something big to ultimately happen at the end
of the project. But for the day-to-day
management of the project, you probably want a slightly
different approach. That's where a Kanban style
view in a tool like this or maybe a Trello allows you to manage things from
a day-to-day basis, where the focus can be on the specific tasks that are being worked on in that
given point in time. You're not being ground now by the bigger picture
view of the world or the Gantt chart view showing. Number 2, Kanban swarming approach versus
designated tasks. In this instance
that we've got here, the danger of a traditional
Gantt chart view, is that when there's resource assignments
assigned to those tasks, you might have Bob assigned to task A or Claire
assigned to task B and often this creates some siloing in the activities that you've assigned them down. In a Kanban approach like this, then it's all about
creating flow, being able to move
tasks from one area to the other and getting the
team to help each other out, encouraging others to see what's happening,
what's being worked on, what gets stuck, and create that shared ownership
and team spirit. It can really help things
move forward here. Whatever approach
you might take in, then try and create
the right environment where you're encouraging flexibility and willingness to help each other out on tasks. This might be something
you just apply maybe on your critical path
tasks, if needs be. Three, sprints to create alignment irrespective
of the schedule type. I'm a big fan of keeping the focus on the here
and now of the project. It's called project
presence at its best. Now, in the Scrum methodology, there's the concept of a sprint, where you choose
only a selection of activities for the next
period of your time, for example, the next two weeks. The teams then focus only on this work and they
evolve retrospectively, from one sprint to the next. Now, this is a fantastic
tool in order to keep focus on just what
is in front of you. Aligning these to an
outcome like hitting a milestone or key event
means that the focus at all times is only
on the thing in front of us and not on the
big picture of the project, which can often be daunting
for people to see. Sprints now can be applied to almost anything in a project in a manner of different ways. You certainly don't
have to be following a Scrum methodology
in order to use it. In this example, we're going to take all the tasks
that are leading to a key milestone in the
project, which is a demo. We're going to use
the Kanban seltzer to filter all of the tasks that are in our Kanban view on those that are associated
with that group of works. What we're going to do
is still work in demo, but what we see now
is that Kanban view, which is really focusing purely on the next period works, it's going to enable the outcome that
we're looking for in that demo at the end of things. So, we can keep the team
fully focused in this view, not being distracted at all by that big picture view
of the Gantt chart, but just keep all tasks
focused on what needs to happen in the next week or
two to get the job done. Use the sprint concept or current period of
time to focus in, and then use a retrospective at the end to reflect on
what you've learned, and then zoom out, look at what it means
to the larger plan. Advice for life here, don't get pulled into a
wall of methodologies. Assess your project, your
working environment, and all of the tools
at your disposal in order to create efficient
ways of working to help show both the big picture and to keep alignment motivation of focus on the here and now
of your project. Before we sign off, think about what we've just discussed, and look at how you can apply all the schedule or in tracking techniques and concepts to
level your projects even more. Remember, there's
always another way.
5. Final Thoughts: [MUSIC] Planning, scheduling, and tracking projects
is what we do. It's part of the job, but there are many
ways to do this. Every environment is different, every project is different, and every organization might ask for slightly different
things from us. It's important to be open-minded therefore and try
different approaches, and always look to improve by choosing the right tool
for the right job. I hope you enjoyed this
class and are able to apply some of these
tactics to your projects. It's always enjoyable
to hear how people get on with
these concepts. I encourage you to share
your thoughts or any of your own lessons learned in
the discussion boards below. Thanks for watching,
and I'll see you again.
Matt Corroboy, Projects, leadership, life and mindset.
