4.1 Project Planning Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

Video Transcription
hello and welcome to the first installment of less than four Project planning.
I'm your instructor,
coach, facilitator, Whatever term or for you, Cane.
Today we're gonna go over the project planning part of the Project Life cycle, and this is a really important part. And so we're going to spend a pretty good amount of time on it
because it's basically where the science and art of project management comes into play. And we're gonna do that little bit more. Uh,
later on,
however, the first thing I wanted to show you is a
snapshot of zoom in of a process chart that I built for the Project Life Cycle. You confined the link to download this below the video.
But in this section, we've kind of got the brew,
the initiation phase, which is that top diamond there that says is the project approved for planning,
and that phase speaks to the idea. Is it a good idea? Should we be doing this on Dhe? Then? As we get into the project planning phase and we become more detailed and progressive elaboration within project planning
before we actually start the execution of the project,
we don't ask ourselves the question of Can we do it? Are we able to do it?
Um, the cantor should kind of interchangeable. But the basic premise behind this is
if it's a good idea and we should be doing it,
that information should be made available during the initiation phase when we're using that investment mindset that we talked about in the previous videos.
Once we've entered into the planning phase. Now we're looking at the detailed information on what sort of really effort
that we're going to have to expend both resource is as well as monetary
in order to achieve the objectives of the project. So in this scenario, especially with enterprise Project Management, when we're dealing with very large, complicated projects, we generate a fairly decent amount of documentation. So if you look at the left there,
you've got a myriad of plans
that you're potentially going to use.
Uh, the
plan summering, scoping objectives, the work breakdown structure,
the organizational in government structure and what we talked about during the Project Charter practical exercise and the video,
and that speaks to how we're going to go about managing change and people on boarding and offering the project know these kind of things
the budget, how we're going to spend it, that suspend plan, the communications plan. Speaking to how we're going to communicate to all the various stakeholders. How often What type of information do they need? No, during the life cycle of the project, how are we gonna manage change? How are we going to manage the quality?
And this speaks more toward the
performance constraints. Speaking about the what the thing is supposed to be able to do, how well it's going to do it. What happens if we do some testing? And we find out that that quality is not what we originally needed? Deliverable acceptance plan risks and issue management plans?
Ah, procurement management plan and that one is very common.
Four. Enterprise Project Manager
Enterprise Project, I should say,
because, as you can imagine,
when you take on these very large scale enterprise projects,
more often than not, there's going to be some sort of large scale procurement. Whether it's just a consultant, a software company, some sort of vendor that's gonna come in to provide additional resource is to achieve the objectives of the project
as we get into
some of the more details. Within the planning phase, we might look at different statement work, which is a contractual obligation. That sort of reflects what the project Charter says, deliverable acceptance. All of these things that we've talked about in previous videos when we're doing a procurement
become much more formalized because that is, the mechanism by which your organization gets the goods and service is that they requested and by which the vendor that you hired gets gets paid.
So if you're on, if you're managing enterprise level project, you can expect to do quite a bit of procurement management and contract management. And you want to make sure that you address those during the planning phase because
just because in the contract or because the vendor says they can do it doesn't necessarily mean that
it's gonna be successful. So you need to do your good project planing prior to engage in the vendor, have that project charter, and don't just take the benders word for it that they Condoleezza whatever system or whatever it is that you want them to deliver,
you will have often organizational change management plan.
This speaks to
these large scale enterprise projects there very often going to radically alter the organization. How do you go about managing change, Who we communicate with, who's messaging to the organization or the agency about the change and all that kind of stuff, which is almost its own?
I mean, his own career field never minded. So of course,
the security plan requirements. Traceability matrix. If you're doing a requirement space project or deliverables based project,
you'll often have traceability. Matrix is just to make sure that everything rolls up successfully, you'll have some sort of compliance assessment. So during the planning phase, you're going to generate lots and lots and lots of plans on, especially on enterprise project.
Once those plans are complete, you could have a much better idea of the scale of the effort that's gonna be required to bring this project to life. And that's when you go through your next phase gate, which basically says, Okay,
we've done our due diligence is going to take X amount of people X amount of hours. This type of procurement.
This is sort of the ballpark rough order of magnitude of what we're looking at for an investment.
Is the organization even able to execute a project of that size, so that's kind of where that comes from. And again, you can download that pdf file below this video to get an idea of what an entire Project lifecycle flow chart may look like.
So, in that detail planning phase, we're going to do what's called a work breakdown structure in a work break down structure
like I said, sort of the art and science of project management. A good project manager
should be able to, and this is all very ideal. I get it.
What should be able to plan the project in such a way that it is accomplished in the exact
minimum amount of time required to achieve the objective of the project? So that sounds kind of
catty. Want piss? But basically what I'm saying is, is that you can't
you nine women can't have a baby in one month, so there's a certain amount of time that you can no longer at add. Additional resource is to reduce the time of the project.
Things just have to sort of go in the order that they go. So this is an example of very, very complicated
enterprise level software project and you can see that there are numerous dependency. Use those little blue lines there. Show what? The dependencies, our of the different bodies of work.
This is called a perch art, which stands for a program evaluation review technique. And this was actually developed by the Navy in the 19 fifties during the Polaris Missile program so they can't can't with the idea that we needed to lay all this,
these work packages out
and figure out what really is dependent upon what?
What that leaves too often times
is a
can chart. This is in Microsoft Project, which is a pretty common product management software that shows
again what's depending upon what? How long these things takes. This kind of takes that perch art and overlays it on calendar to give you an idea of how many calendar days a project might be. So this seems
for a period for class, I should say this seems to be excessively complicated, and it's not excessively complicated. It's just the right amount of complicated, and we'll we'll learn more during the next video. How to go about building one of the more complicated ones. But for now, let's just make sure we understand
the concepts, so
that may be too complicated. Let's start with something simpler. Let's make a pot of coffee.
They might be asking yourself, Is making a pot of coffee
even a project?
And really, the answer is, it depends. If you're like me and you live on coffee, then no, it's not a project. It's definitely part of the operational part of my day.
But if you've never made a pot of coffee before, then you can kind of consider it a project. It's got a definitive start date, a definitive end day. It's a single product or service that you're developing, and there's all these unknowns because you've never made one before.
So the first thing that we want to do is you want to break down
this project of ours, build a pot of coffee into the tasks that it's going to take to accomplish that objective so you'll see here that we're gonna get water.
Get the coffee pot out, plucking coffee pot in. Get the coffee grounds to get the filter. Pour the water into the pot for the ground in the filter, filter into the pot, turn coffee on port in a Cup and then drink it.
But as we've done our bottom up work breakdown structure, that kind of makes sense. Okay, if I follow these instructions, then I could make a pot of coffee. Okay, so that's just general
following a standard operating procedure.
Now the magic starts to happen.
What is the fastest in the shortest amount of time
that I can possibly make a pot of coffee.
So what we're gonna do is we're going to determine what items are dependent
upon the other items. And if you notice these tasks here are all the same past that we listed out here.
But now what we're doing is we're determining what is dependent upon what
so I can get the cop or get the water out
and the coffee pot out and the coffee grounds out and the coffee filters
at the same time. If I have enough, resource is so if I have four different people, they can do all that at the exact same time.
And then we follow along from left to right. You'll see that we can pour water into the pot
while plugging it in
while putting the grounds into the filter. Those things or not
dependent upon each other so they can happen if I again. If I have enough resource is,
then you see put the filter in, turn coffee on important cup to drink it.
So this perch art is showing us that the
scientifically shortest amount of time that we can make a pot of coffee if we had an unlimited amount of resource is is that longest line there that five steps at the top. So if I had a small army of people waiting for me in the kitchen, I could still only make a pot of coffee as fast as I can accomplish those top six items.
Now, if you look at the duration, I'm using days because obviously going minutes or hours is too difficult for the software to map out. But if I find shoes days instead of minutes
when I create a GAN chart
now you can see that same per chart
over late on a calendar.
And again, we're assuming that this calendar in minutes. But you can see a couple interesting things here, So if you look at
the red lines versus the blue lines
and you notice that the red lines match with that top row on our perch art.
What that is is the critical path. So those are the items that have
have to be accomplished in order
in order to complete this pot of coffee project.
And the critical path is important to know because it has to do with the amount of flexibility that you'll will or will not have on those tasks. So the term is called slack. In essence,
Critical Path tasks do not have any slack if they are late. Your entire project is late,
however, if you look at the second line item there where it says, get coffee pot out.
That's complete before the pour water into the pot, so there's what they call slack There.
I can be a little bit late getting the coffee pot out, and my project will still be done on time as long as I don't exceed the available slack that I have in that task.
And if you look at tasks the poor grounds into filter, it's the same thing. I have a delay there
of a period of time before
the put filter into the pot task.
It has a hard start date so that slack. So part of the art
of being your project manager is knowing where your slack lies and being able to
manager project in such a way because Murphy's law is what it is that some items may be late, but that my overall project and still be accomplished on time. In addition, if my critical path tasks are late, the sooner I know that the sooner I can take her mediation actions in order to get the project back on time.
So this illustrate some of the skills that are required in the planning phase. And this is a waterfall project will get into more detail on on different types of project planning. But for now, we'll just call this project scheduling
in this project.
By going through the planning phase and building out my schedule, I can see certain things, certain opportunities and certain risks, right? So my critical path is almost always a risk unless I get something done early, which is great,
and then that becomes an opportunity. But even within this simple, simple
pour a cup of coffee project, you can see that I have some opportunities to
moved. Resource is around in order to support the entire project
by delaying certain tasks that have available slack in them.
So again, thank you for joining in the next video. We're actually gonna take these principles and apply it to our May software project.
I think you have a great
Up Next
4.2 Project Planning Part 2
4.3 Project Planning Part 3
5.1 Project Execution and Closure Part 1
5.2 Project Execution and Closure Part 2
5.3 Project Execution and Closure Part 3