00:00:00
what's up guys and welcome back to my
00:00:01
channel for toll in motion a place for
00:00:03
busy people and Dream Chasers look to
00:00:06
achieve their goals in a more efficient
00:00:07
way so if you're new here hello welcome
00:00:09
my name is IRA and I do project
00:00:11
management self-improvement and the
00:00:13
occasional lifestyle video so please do
00:00:15
hit that subscribe button if that's
00:00:16
interesting content to you and to my
00:00:18
lovely subscribers coming back for
00:00:20
another video hello welcome I hope
00:00:24
you're doing good let's get straight
00:00:25
into this one alright guys so today I'm
00:00:26
coming back with a highly requested
00:00:28
video and that's basically just breaking
00:00:30
down the main types of project
00:00:31
management documentation which you need
00:00:33
for any successful project delivery now
00:00:37
through the whole Project Life Cycle
00:00:38
there'll be many types of documentations
00:00:40
you will need to either create maintain
00:00:42
track or just have an input into but the
00:00:46
ones that I'm going through right now in
00:00:48
my opinion are the most important the
00:00:51
essential ones and there's 10 of them
00:00:52
and also I'm giving you real life
00:00:54
templates and examples in this video so
00:00:57
you can have a better understanding of
00:00:59
the type of thing things that you may
00:01:00
need to create all of these
00:01:02
documentations can be created on either
00:01:04
Excel or word but there are also a lot
00:01:07
of online automated tools that can help
00:01:10
you do it a lot faster so I'll just be
00:01:12
getting straight into it and just to
00:01:13
make it a bit more useful to you guys
00:01:15
I'll be breaking down wearing the
00:01:17
Project Life Cycle you will either
00:01:19
create or need to input into these
00:01:21
different documentations so I'm hoping
00:01:24
you know you guys if you're starting on
00:01:27
a project you just don't know where to
00:01:28
start don't know what documents you need
00:01:30
at different phases of the project just
00:01:33
a video for you make sure you go share
00:01:34
it it's going to be a good one let's get
00:01:36
it popping first of all we're going to
00:01:38
start off in the initiation phase and
00:01:40
the first documentation you will come
00:01:42
across is the business case the business
00:01:43
case provides justification for why a
00:01:46
project should be undertaken it helps to
00:01:48
explain how the benefits of undergoing a
00:01:50
project outweigh the costs and why it
00:01:52
should be executed so of course by
00:01:54
definition this needs to be the first
00:01:56
documentation that you come across why
00:01:58
even is this project project happening
00:02:00
before we start to talk about the how
00:02:02
we're gonna make it happen overall
00:02:04
include the summary of all the projects
00:02:06
objectives costs benefits basically
00:02:09
everything that stakeholders need to be
00:02:11
convinced to take on the project and get
00:02:13
on board it will also weigh up
00:02:15
alternative solutions to the problem
00:02:16
statement that the project is trying to
00:02:18
solve But ultimately it will conclude on
00:02:21
why this preferred solution which is in
00:02:24
the business case is the one that we
00:02:25
want to take forward all right so on the
00:02:27
screen I'm going to get up an example of
00:02:29
a business case and once again this is
00:02:31
something that could be made in Excel or
00:02:33
word so it's fairly simple for all and
00:02:35
these are kind of the main features that
00:02:37
you can expect to see in a business case
00:02:39
first of all you're going to have the
00:02:41
Strategic context and that's basically
00:02:43
just a compelling case for why we want
00:02:46
to do this change it will include the
00:02:48
problem statement and how we plan to
00:02:50
overcome it by this project then the
00:02:52
business case we'll go into the economic
00:02:54
kind of analysis the return on
00:02:56
investment what is based on the
00:02:58
different options but you know why the
00:03:01
option in The Proposal is looking the
00:03:03
most tantalizing or why we should take
00:03:04
that one forward of course you need a
00:03:06
brief Financial case and this is looking
00:03:08
at the costs and the resources that it
00:03:10
will require from the business whether
00:03:12
they actually have the capability to do
00:03:14
this or whether they'll need to get
00:03:16
additional resources Etc how much things
00:03:18
will roughly cost at and then how much
00:03:20
time and then lastly we're looking at
00:03:22
the management approach so this could be
00:03:24
everything from like roles governance
00:03:27
structures those kind of things there
00:03:28
trying to set the pace maybe some high
00:03:31
level risks as well at this time we
00:03:33
don't really know the detail of how
00:03:35
we're going to make it happen we just
00:03:37
kind of know all right if we do bring
00:03:38
this to the table this may be something
00:03:41
that we may encounter we need to take it
00:03:42
into consideration in this justification
00:03:45
remember the justification can't just be
00:03:47
one-sided you know it can't just say
00:03:49
this is the problem we have this is how
00:03:52
we're going to fix it and it's all going
00:03:54
to be bells and whistles no no they
00:03:57
don't know they don't know that there's
00:03:59
cap there's all always got to be a very
00:04:01
balanced view let them know in that
00:04:03
business statement okay this could go
00:04:05
wrong however if we don't do this this
00:04:07
is what's gonna happen and ultimately
00:04:09
the benefits outweigh the costs and that
00:04:12
is the justification one last thing to
00:04:14
highlight then it is the project sponsor
00:04:16
that is responsible and owns the
00:04:18
business case document however the
00:04:21
project manager and other stakeholders
00:04:22
may have input and should really have
00:04:24
input into that document the project
00:04:27
manager although you do not make the
00:04:29
business
00:04:30
um case in some in most aspects I would
00:04:33
say in most organizations in some they
00:04:35
may if it's a smaller organization but
00:04:37
generally they don't they will
00:04:39
definitely still need to be across that
00:04:41
business case know it inside out so that
00:04:44
when you are delivering you are able to
00:04:46
refer to it and make sure that your
00:04:48
delivery is fit for purpose so also in
00:04:50
the initiation stage as a project
00:04:52
manager you will be asked to make
00:04:54
something called a project Charter and
00:04:56
for me project Charter is one of the
00:04:59
most important content documents to a
00:05:01
project manager I'm going to tell you
00:05:03
why the project Charter is a form of
00:05:05
documentation that outlines the business
00:05:07
objectives for doing your project and
00:05:10
once it's approved it will then initiate
00:05:12
the project it's made in line with the
00:05:14
business case and in many times people
00:05:16
ask me isn't that just the same thing
00:05:19
you said for a business case it is very
00:05:21
very similar but in summary the best way
00:05:23
I like to describe it is the business
00:05:25
case is the case for why we should do
00:05:28
the project but the project Charter is
00:05:31
the first instance where we say how
00:05:33
we're going to deliver the project so
00:05:35
I'm going to get up an example of a
00:05:37
project Charter on the screen right now
00:05:38
and just go through some of the main
00:05:40
elements so what you can expect to see
00:05:42
on a project starter of course you
00:05:44
expect to see the project name the
00:05:46
project sponsor the project manager's
00:05:48
name Etc the rationale for the project
00:05:51
so that could be the problems problem
00:05:53
statement and then also expected
00:05:55
benefits at a very high level these
00:05:56
things are also seen on the business
00:05:58
case
00:06:00
um but then going into a bit more detail
00:06:02
we expect to see the objectives
00:06:04
um and also the goals how we're going to
00:06:06
measure success Etc some of the key
00:06:08
deliverables so now we're getting a bit
00:06:10
more in the nitty-gritty would have got
00:06:13
with your team a little bit and
00:06:14
understood okay fine how are we gonna
00:06:17
get there what are the key things we
00:06:18
need to do the key milestones and
00:06:20
perhaps a timeline at this time it's not
00:06:23
likely to be very detailed at all
00:06:26
remember this is a very high level
00:06:28
document a brief summary of the costs
00:06:31
and resources are also expected to be in
00:06:33
this document key stakeholders usually
00:06:35
the decision makers or the key people on
00:06:38
the team like the key architect key
00:06:41
um engineer Etc a list of the key and a
00:06:44
saying key because you know you're not
00:06:46
meant to list out everything here I just
00:06:48
want to see the key constraints and
00:06:51
dependencies assumptions risks as well
00:06:54
hopefully there are no issues at this
00:06:57
time but if there is one already make
00:06:59
sure you put that in also you'll be able
00:07:01
to see the scope exactly what we're
00:07:03
going to do and usually high level out
00:07:06
of scope what we're not going to do in
00:07:08
this project and then lastly a success
00:07:10
criteria or an acceptance criteria so
00:07:12
how do we know that the Project's done
00:07:14
at what point at the end we can
00:07:17
confidently say yeah we did our damn
00:07:20
thing all right so moving to stage two
00:07:22
in the Project Life Cycle the planning
00:07:25
stage and in this stage the first
00:07:27
document that you're likely to come
00:07:28
across is your project schedule the
00:07:30
project schedule indicates what needs to
00:07:32
be done what resources need to be
00:07:34
utilized and also when it's going to get
00:07:37
done it's a timeline that highlights the
00:07:39
start and end date and also the key
00:07:41
Milestones that must be met in order to
00:07:43
complete the project on time now I've
00:07:45
already done a full comprehensive video
00:07:48
on how to make a project schedule so
00:07:50
make sure you go make sure you go look
00:07:52
at that make sure you go look at that
00:07:53
that was a decent video so I'm not going
00:07:54
to go into too much detail but in terms
00:07:57
of the key things that you can expect to
00:07:58
see I'll just get up on screen now a
00:08:01
nice little template you should really
00:08:02
expect to see the key deliverables
00:08:05
Milestones any dependencies between
00:08:08
different tasks a timeline usually in a
00:08:11
Gantt form is really helpful and then
00:08:13
also the resources that will be carrying
00:08:16
out that work if you're a project
00:08:18
manager or project scheduler this will
00:08:20
be your baby I'm telling you this now if
00:08:24
you are in a position where you're told
00:08:25
to put together a project schedule make
00:08:27
it as comprehensive as possible make
00:08:30
sure you know your what you're doing or
00:08:32
what your team are doing every single
00:08:34
day because every single day you're
00:08:37
going to be expected to deliver and it's
00:08:38
always great to have a good reference to
00:08:40
go back to so you know exactly what is
00:08:42
meant to be happening also in the
00:08:44
planning stage the project manager will
00:08:46
work with the team to come up with the
00:08:48
project budget now the project budget is
00:08:50
a plan that details how much you will
00:08:51
spend on the project when and also on
00:08:54
what this document is also very
00:08:56
important because as a PM you are
00:08:58
expected to manage the costs on the
00:09:00
project and you need to be able to see
00:09:02
what your target is and manage the spend
00:09:04
as you go along I've also made a
00:09:06
comprehensive video on how to make a
00:09:08
very simple project budget so make sure
00:09:10
you go and check that one out as well
00:09:12
but in terms of the main elements of a
00:09:14
project budget we're looking at what
00:09:17
we're going to spend so this could be
00:09:18
both resource costs and also NRE
00:09:21
non-recoverable expenditure they'll also
00:09:24
be either a timeline or a month by month
00:09:27
breakdown of when you're expected to
00:09:29
spend that money and then lastly how
00:09:31
much money you're going to spend next up
00:09:33
also in the planning stage you'll start
00:09:35
to develop your risk and your issue log
00:09:38
once again I've done a comprehensive
00:09:40
video on this but in summary is a
00:09:43
document that highlights all of the
00:09:45
project risks and issues and also your
00:09:48
plan for keeping them under control
00:09:50
there's no point just highlighting it
00:09:51
this is a risk this is an issue and not
00:09:54
telling people but this is how we're
00:09:56
gonna contain it I'm just gonna get an
00:09:58
example up on the screen screen so you
00:10:00
can see the key elements usually we have
00:10:02
an identification number and also a date
00:10:05
of Entry so we know exactly when this
00:10:07
risk or this issue popped up a
00:10:10
description of some kind the impact of
00:10:13
this risk or issue if it's already
00:10:15
happening what is going to happen how
00:10:18
will this affect my project kind of
00:10:20
thing the likelihood of it happening
00:10:22
it's severity
00:10:25
um the owner someone always needs to be
00:10:27
assigned as the owner someone that needs
00:10:29
to be looking on it someone that needs
00:10:31
to be making sure that it's still
00:10:33
relevant and then the project manager is
00:10:35
always working with those people to keep
00:10:36
the log updated and then of course what
00:10:40
is most important those preventative
00:10:43
actions those mitigations and
00:10:45
containment actions what are we doing to
00:10:47
control this all of this will be your
00:10:49
risk and issue log remember guys a risk
00:10:53
is something that may happen on your
00:10:55
project and cause a detrimental effect
00:10:57
but an issue is something that already
00:11:00
causing a detrimental effect so we need
00:11:02
to make sure we track both of them even
00:11:04
in the same document or in a different
00:11:06
document I advise keeping two separate
00:11:08
documents for this all right now coming
00:11:11
out of the planning stage and into the
00:11:13
execution slash monitoring slash control
00:11:18
phase I'm I'm just merging the phase
00:11:21
three and phase four in the Project Life
00:11:23
Cycle because really and truly you're
00:11:25
going to be using all of these documents
00:11:27
in this phase first up then we have the
00:11:29
change request document and the change
00:11:31
request document records all of the
00:11:33
changes that have been requested since
00:11:35
the project was baselined so if you
00:11:38
don't know what Baseline is effectively
00:11:40
once you've started the initiation phase
00:11:43
and you've done your planning you get
00:11:45
your budget you get your um
00:11:48
schedule you get your risks and your
00:11:50
issues and you basically say this is
00:11:52
what I'm going to do in this time and at
00:11:55
this cost this is the Baseline any
00:11:58
change to what we're gonna do right
00:12:00
needs a change request and I need to
00:12:03
highlight this guys because that's where
00:12:05
you get something called scope creep
00:12:06
which can be absolutely detrimental to
00:12:08
your project you need to be able to see
00:12:10
when people are requesting extra things
00:12:13
um that may change what you initially
00:12:15
said you're going to do changes may have
00:12:18
an impact on your timeline and may have
00:12:20
an impact on your budget and this all
00:12:22
needs to be assessed different
00:12:23
organizations handle change requests in
00:12:26
different ways but generally what will
00:12:28
happen is someone will request a change
00:12:30
you log it down in a document it might
00:12:33
be a separate team that does it it might
00:12:34
be the project manager that does it I'm
00:12:36
just going to put up a simple example on
00:12:38
screen now and in here effectively
00:12:40
you'll have details about what the
00:12:42
change is the impact of doing that
00:12:45
change if we didn't do that change what
00:12:47
would the the detrimental impact to the
00:12:50
project being but then you also need to
00:12:52
understand what the impacting parties
00:12:54
are who needs to assess this change and
00:12:57
also any impacts to them in terms of the
00:13:01
time and the cost implications for doing
00:13:03
this change I always like to make sure
00:13:06
that the status of the change request is
00:13:07
also noted in there so this could be
00:13:09
ongoing pending approved or rejected and
00:13:13
then of course there needs to be a final
00:13:15
status at the at the bottom saying
00:13:17
either approved or rejected not all
00:13:20
change requests are gonna happen you
00:13:23
know if you have a change request then
00:13:24
someone says yeah it would be really
00:13:26
nice to do this because it will improve
00:13:28
user experience by two percent or 0.2
00:13:31
percent something something marginal but
00:13:33
it's going to cost us two mil
00:13:35
once you've done the assessment they
00:13:37
might be like you know what
00:13:39
they uses that really
00:13:41
next up then we have the defects log and
00:13:43
the defects log is just a simple
00:13:45
template for logging down any defects or
00:13:48
errors or something that is not working
00:13:51
as it should whilst you guys are testing
00:13:54
the solution that you're implementing so
00:13:56
usually we do see this more in the
00:13:58
software space where we're doing
00:13:59
software
00:14:01
um kind of um projects however I do
00:14:04
Hardware projects and I have a defects
00:14:06
log because sometimes we're testing that
00:14:07
hardware and it's not doing what it
00:14:10
should be doing I need to note it down
00:14:13
I'm gonna get an example up on the
00:14:15
screen right now just so you can see the
00:14:17
kind of things that I would put in my
00:14:18
defects log obviously we want a defect
00:14:21
number a description of that defect also
00:14:24
how how severe is that defect how much
00:14:27
is it impacting us as of now I love to
00:14:30
put the date it was logged just so I can
00:14:32
measure how long it's been open and also
00:14:35
when it needs to be completed by so a
00:14:38
Target completion date and that's really
00:14:40
important because some defense that's
00:14:41
fine they're not that severe right now
00:14:44
we have time all the way until next year
00:14:46
or the year after to close it down but
00:14:49
as we're getting closer to that Target
00:14:52
completion date believe me it's no
00:14:54
longer green it's now turning Amber it's
00:14:56
now turning red I can use that to
00:14:58
prioritize which of the defects that I'm
00:15:01
triaging and fixing lastly it's also
00:15:03
good to put how it was fixed or what
00:15:06
Sprint if it's software roll out it's
00:15:08
going to be fixed in
00:15:11
um and then also if it's open or closed
00:15:13
just something so people can know if
00:15:15
it's still an issue if it's fixed if it
00:15:17
is fixed where is it fixed and then we
00:15:20
can also have great traceability next up
00:15:22
we have the executive project status
00:15:24
report and guys this one you need to
00:15:28
make sure you have this one just
00:15:29
constantly in your back pocket it's
00:15:32
effectively a document that just
00:15:34
highlights the most important
00:15:36
information on your project at that
00:15:39
given time and I'm saying executive
00:15:40
report because it doesn't need to be
00:15:42
detailed you usually you just want to
00:15:44
pull it out of your pocket when someone
00:15:46
wants a status update how's it going
00:15:48
what are the main things going on
00:15:50
usually execs or Pete someone um that
00:15:53
you report into will ask for this on a
00:15:55
weekly or monthly basis so it's always a
00:15:57
good one to always have updated but also
00:16:01
not so detailed so just getting one up
00:16:03
onto the screen right now it would
00:16:05
always have a high level overview of the
00:16:09
current status on the project at this
00:16:11
given time and the progress you've made
00:16:14
since the last time key Milestones key
00:16:17
risks key issues how the Project's doing
00:16:21
um in terms of how much spend Etc the
00:16:24
scope changes so if there are new change
00:16:26
requests it's always good to highlight
00:16:28
that there and then also how resourcing
00:16:30
is going on at the moment just to
00:16:33
highlight once again guys we are talking
00:16:35
about the key we are talking about the
00:16:38
critical don't be in this thing now
00:16:40
every you think you got going on because
00:16:43
not everyone cares we want to know the
00:16:45
key bits here and it's also a tool for
00:16:48
the project managers to take
00:16:50
accountability of their work show their
00:16:52
sponsor the whoever you're reporting to
00:16:54
that we're making progress but also use
00:16:56
it to your advantage if things are going
00:16:58
wrong and you need to escalate this is
00:17:00
the time to say yo you know this may be
00:17:03
detrimental to the project I'm having a
00:17:05
hard time here highlighted in this
00:17:07
status report so whoever you're
00:17:09
reporting to is able to help you usually
00:17:11
when you're doing a status report it's
00:17:13
for someone that you're reporting to
00:17:14
they have more influence so they may be
00:17:16
able to escalate it and get it done for
00:17:19
you all right so now moving on to the
00:17:21
closure phase of a project this is where
00:17:24
you'll start to see the Lessons Learned
00:17:26
log this log is used to capture and
00:17:28
share knowledge about what has worked
00:17:30
well on the project and what could have
00:17:32
been done differently in the future it's
00:17:34
really a document for the benefit of
00:17:36
future project managers that will be
00:17:38
taking on similar projects so they don't
00:17:40
repeat the same mistakes that you and
00:17:43
your team have had to go through in
00:17:45
order to get to the end of the project
00:17:46
so I'm going to get one up on screen
00:17:48
right now just so I can go through some
00:17:50
of the key aspects I usually do put a
00:17:53
log number and a title just a brief
00:17:56
description after that as to what the
00:17:59
lesson was how did it come about how it
00:18:02
was identified and by whom and basically
00:18:05
you know how you would do it differently
00:18:08
next time it doesn't need to be long
00:18:10
whatsoever but like I said it really is
00:18:13
just for the benefit of whoever's gonna
00:18:15
pick up a similar project they can go
00:18:17
back to this log and say okay they did
00:18:20
this don't do that again don't do that
00:18:22
again we save a lot of time we tame cost
00:18:25
and it's really just um about helping
00:18:28
out your fellow PM do not wait until
00:18:30
project closure before you start filling
00:18:33
in information into this log I know in
00:18:36
most of the books it does say it comes
00:18:37
out at this closure phase but from my
00:18:39
experience you're going forget all the
00:18:42
bad things because you're just
00:18:43
constantly firefighting moving forward
00:18:45
it's better that if you notice
00:18:47
something's gone wrong during the
00:18:49
project during execution phase you start
00:18:51
to note it down you start to talk to
00:18:52
your team yeah we ain't doing that again
00:18:54
let's write it down so that when you do
00:18:56
get to the closure phase you're
00:18:58
literally just bringing your team
00:18:59
together is there anything else we have
00:19:01
missed out cool write it down or good
00:19:04
and then lastly we have the project
00:19:06
closure report and this report is
00:19:09
basically the final documentation you
00:19:12
will have in a project which basically
00:19:14
says this is what I said I was gonna do
00:19:17
but this is what I gave you
00:19:19
are we okay to close the project
00:19:21
basically it'll be used by various
00:19:23
stakeholders to just assess the success
00:19:25
of the project and I'll get an example
00:19:27
up on the screen right now as a project
00:19:30
manager you will be expected to put this
00:19:33
together doesn't need to be long it just
00:19:35
needs to be clear it just needs to have
00:19:38
all the relevant details so a summary of
00:19:40
what the project was the key people
00:19:43
responsible as well will be in there
00:19:45
your key deliverables when you said you
00:19:48
were gonna do it this is when it was
00:19:49
actually done it's always great to have
00:19:51
those two bits of detail for learning in
00:19:54
the future same with the cost as well
00:19:56
how much you said you were going to
00:19:58
spend versus what how much was spent at
00:20:00
the end and then Lessons Learned could
00:20:03
also be integrated into this success
00:20:05
criteria also good to put on here let
00:20:08
people know this is what we said you
00:20:10
know was going to be the success and how
00:20:12
we would know that this
00:20:14
um project is successful and completed
00:20:16
and this is what we've done a nice
00:20:18
summary for every everyone then you'll
00:20:20
give it to the project sponsor and they
00:20:22
will sign it off and say Yes happy for
00:20:24
this project to be closed and yeah that
00:20:26
is basically it guys 10 documentations
00:20:29
that are really essential for project
00:20:32
delivery especially if you want it to be
00:20:35
successful there's so many more like
00:20:38
I've said but these ones if you are
00:20:40
signing off a project do you really try
00:20:42
to make sure that you have them in place
00:20:44
so that you are able to navigate quickly
00:20:47
and easily all right guys so that is it
00:20:50
for this video I hope you enjoyed it I
00:20:52
hope it was useful for you if it was
00:20:53
useful for you please do give me a big
00:20:55
thumbs up and make sure you subscribe to
00:20:58
this channel because guys the new year
00:21:01
is coming and I've had a little word to
00:21:03
word with myself and said Ira you need
00:21:05
to come back for some fires and next
00:21:07
year 2023 it's going to be a great year
00:21:09
for Content I'll be seeing you very very
00:21:12
soon and take it
![Project Management Basics - Part 1 [THE ULTIMATE STARTER PACK]](https://ruhnrawpgxrzdrgaohnf.supabase.co/storage/v1/object/public/images/video/IJH17vkF2wg/thumbnail.jpg)
