Hi, I'm Brett Harned, Director of Education for TeamGantt.
Today we're going to talk through top 10 terms
about project management.
Now, these might not be your top 10 terms,
but these seem to be the ones that
carry a little bit of weight for people
who are leading projects.
And I'll say, these aren't in any specific order.
I'm just going to kind of run through the top 10
that I think we should teach you about.
Let's jump in.
The first term is requirements.
Requirements are conditions or tasks
that must be completed to ensure the success
or completion of a project.
So requirements can take a lot of different forms.
You'll see them as listed formal business goals.
You'll see them in spreadsheets listing
specific features or functions that are required in a project.
You'll see them listed as tickets
in a system for a developer or a team member
to pick off and work on.
You'll even see requirements listed on a whiteboard.
Just kind of an informal way of saying,
hey, these are the things that we need to do on this project.
No matter what you do, you should make sure
that your requirements are documented in some way
that everyone can easily understand them, update
them, and say, hey, this thing is done,
or there's an issue with this thing.
Some projects won't have requirements
at all, specifically smaller, quicker projects.
And that's OK.
What you have to do is just be flexible and make sure
that you're doing what's right for the project.
But when you do have project requirements in place,
you can rest assured that you're on track
and you're doing the right things.
Our second term is project plan.
A project plan is a document that
defines a project's process, tasks, milestones,
and assignments while taking scope and deadlines
into account.
We talk about project plans a lot at TeamGantt,
and that's because we make software that actually
makes planning really easy.
As a PM, I've created a lot of project plans in my day.
And I can say that the project plan is probably
the most important document on any project,
because it sets the expectation for when tasks are happening,
who is assigned to them, and how they
contribute to the long term success of a project.
Project managers are usually responsible for creating
and managing plans through a project,
and they're typically living, breathing documents that change
over the course of time.
So using a software or tool like TeamGantt
can help you to manage that.
Our third term is milestone.
And a milestone is an action or event
that marks a significant event or change on a project.
So you may use the term milestone
in your life for significant events.
Things like weddings, births, or even historical milestones
that have happened throughout the course of the history
of the country or the world.
A significant milestone that I can think of
is July 20, 1969, when Buzz Aldrin landed on the moon.
So if there were a project plan for the Apollo 11,
you would see on the Gantt chart a little diamond
that signifies the milestone of landing on the moon.
Now, how would you relate that to a project, let's say,
within your organization or in the project management world?
Think about things that are milestones in your projects.
That could be large significant meetings, deliveries
of deliverables, or meetings about those deliverables,
or even the launch of a product or a project.
Those are the things that you're going
to list as milestones on your project plan.
Our fourth term stakeholder management,
which is the process of identifying and engaging
with the people who are responsible for or even
fund a project throughout the course of it.
So stakeholders might be executives, business leaders,
managers, and even clients.
These are the people who are really
controlling your project, the people
that you're talking to and really
trying to get insight and approval
from throughout the process.
Engaging these people for many project managers
can be really difficult, because typically
people at those levels don't have a ton of time
to engage in projects, particularly if they're
one of several that are happening
within an organization.
So having a process in place for engaging those people
and making sure that they're engaged throughout your process
is very important.
For me, working with stakeholders,
I've encountered many challenges.
One example for me was I was working
with an organization who claimed that they were flat,
which made sense for them.
But I knew that getting into a project
scenario with a flat management team
would be difficult when it came time
to make decisions, particularly around things like design
and features and functionality.
So what we did was we sat in a room at a whiteboard.
I listed out the different layers of stakeholders, which
were essentially a core team of stakeholders,
the people who were involved in the project day in
and day out-- or at least on a weekly basis.
Their team, so a first level would
be a marketing team and a second level was an IT team.
So this is a web design project, something
where marketing and IT were definitely involved.
Then there is a layer of stakeholders
who are above that, which might be a management layer.
Maybe they're middle managers, maybe their department heads.
They're people who are definitely
going to have the opportunity to come in and change the course
of the project if they want to.
Above that would be a CEO or an executive level.
And beyond that might even be a board of trustees
or a group that's not necessarily
tied to the organization officially in an org chart,
but definitely has some say.
So what we did was we identified who all of those groups were.
We identified who the people would be within those groups.
And once we were able to do that, I didn't say,
hey, you're not flat.
I said, hey, this is great.
What we can do is identify when we need to engage these people.
So coming up with a plan like that
can definitely help you to set the expectation for how
you're going to engage stakeholders
throughout a process.
Term number five is scope.
Scope is what needs to be achieved
and the work that must be done to deliver a project.
I always say that it's best to start a project with a very
well-defined scope.
If you're not doing that, you're leaving
yourself open to doing more work,
or extending work and adding team members,
extending your budget, just for the sake of someone's new idea
that comes up.
So a scope can come in many forms.
It can come in a formal document, like a contract.
It can come in the form of a project brief.
Or it can even come in the form of an email.
It all depends on the organization you work in
and how formal you are with your documentation process.
I always like to err on the side of creating documentation
and leaving a paper trail for what
should be done in a project.
And that's typically done in a formalized scope
document that's tied to an estimate for a project.
If you're not doing that, you might
want to think about lightweight ways
that you can at least control the scope on your project
and define what your team will be doing.
If you don't do that, you're leaving
yourself open to new requests and ideas
from stakeholders that might come in at the last minute
and change the course of all of the work
that you've done on a project.
This has happened to me several times.
One of the times that I can consider
is building a website for a large media company,
getting to launch day, and a stakeholder coming and saying,
hey, this website's not working on my BlackBerry, which
nobody used at the time.
And essentially, me going back to the scope and saying, hmm,
these are the browsers that we listed in our scope.
BlackBerry's not one of them.
That shut down the need or the desire to do additional work.
If we really needed to do some work on BlackBerry,
I would have then created a change request,
and scope creep would have been cut out.
OK, so our next term is risk.
And risk is an uncertain event or condition that if it occurs,
has an effect on at least one project objective.
Every project comes with some level of risk,
whether that's a missed deadline that creates a ripple effect
on missed deadlines in the future,
or an introduction of new scope that introduces changes
to your plan and how you'll achieve a project.
Good PMs are the ones who are always looking out
for risk and issues.
One good way of handling risks and issues
is by doing a weekly status report.
And in that report, thinking through all of the things that
happened last week, all of the things that are happening
this week, and trying to do a good sort of projection of what
might be coming in the next couple of weeks.
If someone misses a deadline, what's going to happen?
If it looks like someone's going to miss
that deadline documenting it in that status report
and having a conversation about it with your team
and with your stakeholders to make sure
that that issue doesn't actually happen.
The next term is expectation management,
which is ensuring that everyone are project--
both your team and your stakeholders included--
are aware of how the project will work,
how you'll communicate, and how things will get done.
The best way to manage expectations through a project
is through solid communications.
I typically recommend sitting down
at the beginning of a project to make sure
that your team and your stakeholders
alike are aware of how the project is going to work.
So you'll talk through your process,
you'll talk through who is accountable for tasks, when
major milestones are going to happen,
and ensure that everyone is on the same page.
A good way to keep those expectations in check
is by doing a regular status report,
where you can talk through what's
happened last week, what's coming up this week,
and then list any action items or to-do's that people are
accountable for on the project.
It's also a good idea to do stand up meetings, or just
check in with your team to make sure that everyone
is aware of what's happening at all times of the project,
and that everyone's expectations are in place.
Term number eight is status report.
A status report's a detailed and recurring document
that helps you your stakeholders and internal team stay
honest about your work, process, budgets, and issues.
So I've already mentioned status reports quite a few times.
I really think that they're critical to helping people
manage projects really well.
So if you need some help with status reports,
we've got a free template on TeamGantt.
Click on the link in the video, and you can check that out now.
And remember, sending a status report weekly,
bi-weekly, or even monthly is going
to help you to keep expectations in place,
as well as making sure that everyone
is accountable to the flow of information on a project.
OK, term number nine is resource management,
which is creating a forecast or staffing
plan to ensure that teams are assigned to work
and productive and not overbooked.
This is a tricky term, because using the term resource
for people doesn't really go well with people
who you're calling resources.
A friend of mine Meri Williams, who's the CTO of Monzo,
said in a tweet, "If you call people resources,
they're allowed to call you overhead"
to a roomful of people at a project management conference.
It got lots of laughs, and I agree with it.
We shouldn't call people resources.
We are talking about booking people and their time.
But we have to remember that they're just humans.
We're not booking 40 hours and saying this work will get done.
We're making an estimate for what it might
take to get that work done.
So when you're doing your staffing plan,
or even if you're calling it a resourcing plan,
make sure that you're thinking about the people who
are involved, and don't treat those people like boxes
that can be moved around.
So our final term is change management.
And change management is the process, tools,
and techniques used to manage unscheduled change
on a project.
So one thing is for certain--
change is going to happen on projects.
I've never worked on a project where
there wasn't at least a minor change in the way
that we're doing work.
And what form does change take on projects?
Change can come in new goals.
It can come in changing those goals.
It can come through a missed deadline.
It can come through a new idea that comes in
that you have to account for.
There are a lot of ways that projects can change.
And what's important within change management
is having a process for how you handle that change.
So it's communicating that change.
It's making an update to a project plan or an update
to a budget to accommodate for that change.
And then also communicating what the effects
are of that change as your project proceeds.
And there you have it.
Those are the top 10 PM terms.
Like I said, they might not be your terms.
But they're the ones that I thought
were worth mentioning today.
If you feel like we've missed something
or you want to get in touch and talk about it,
please feel free to comment below, or get in touch with us
on Twitter @TeamGantt.
Thank you.
[MUSIC PLAYING]