>> Of the many pitfalls probably one is not taking into account
the precedent relationships and the constraints.
For example, I've,
I've had project managers because a, assembly people were available,.
They scheduled assembly work before the parts arrived.
It was convenient, or if I have a four story building and
I have the fourth story rented, I am going to build the fourth story first.
Forgetting that there are certain relationships that are natural
constraints and
there are legal constraints and not taking into account all of the constraints.
A, building a constrained schedule is basically worthless,
because it can't happen.
Assuming that you have all the availability,
all the people you need exactly when you need them.
And you can drop them off your project when you don't need them anymore.
So I think not taking into account the actual constraint
on you legal, natural, logical and,
though some by government regulation, will, will screw up a schedule badly.
[SOUND].
>> So my advice, always as a season project manager, is always to go back to
the basics, and a lot of times, especially for even seasoned managers.
I think just scheduling in itself is a nightmare and I would say,
to understand, first and foremost, before you do a schedule is the format.
Depending on your company, your client, your industry and
especially your organization, what format did they use.
So we had a project that is so huge,
it's an enterprise to build 70 retailer facing systems and
we had over a 180 pages worth of chart.
And months and months of work and keeping up with it and
as you know chart is just tedious.
But even in the end, it's useless because no one understands it.
Nobody knows how to read it.
My organization definitely do not go by Gantt chart.
So we had to quickly go back and do it in Excel or do it in Word.
I think, most importantly, you should ask yourself first,
what is easiest for your organization or your stakeholders or
your clients, as far as receiving deliverables or phases or schedule.
So, I think that is key.
>> I, I'll chime in and say that there's an old adage in project management.
Plan the work, then work the plan.
And I think it's the second half that kind of gets lost at times.
Unfortunately some project teams look at, plan the work as just an exercise they
have to do, like a checklist item, and then the project plan becomes
like vaporware, just put on the shelf and forgotten.
They're not actually working the plan.
That's one of the things I, I would always advise,
especially when it comes to scheduling is that when you put the plan together it's
not just meant to be a thing you have.
It's something you need to be able to actually execute against, and
I think, as Karen was talking about, it's gotta be readable.
It's gotta be kept up to date.
It's gotta have the dependencies.
But it's gotta be something that the entire team will actually use.
Because that's really going to be your blueprint for executing the project.
>> And I want to add to what Neil said, keep in mind, I think, first and foremost.
And I think Neil mentioned it.
Throughout your entire projects, every single project needs to have this value.
What we're doing for success is value.
So whether it's in budgeting, in schedule, that is key.
And you want to show value because that's how you earn your trust and
ultimately win your project.