6 hours 23 minutes
Hello and welcome back to Enterprise Project Management.
I'm your instructor, Dr Kane,
For today's lesson. What we're going to do is dive a little bit deeper into the specifics of what is a project so that we can later contrast that with operational activities.
So a project
is a specific, unique product or service, And what that means is that projects don't last forever. We do not have projects that,
though they may span years or in some cases, even a decade or more.
Um, they have a defined
completion criteria. So if I were a automobile manufacturer,
one of my enterprise level projects might be the development of a new stand or SUV or something of that nature.
And once that sedan was rolling off the line, that project includes we do lessons learned and we move on to the next project.
Similarly, if I was a I T consultant or night to software firm,
the release of the software to production would be the conclusion of that project.
One of the things to take note of since you are on cyber ery, which is heavily geared toward security professionals
as the risks of I t security continued to increase
in really epic proportions. You're starting to see Maur and Maur security related enterprise projects. So this is a great skill set to have If you're transitioning from I t security into some sort of i t security project management role
because those projects are growing to be enterprised wide.
The project has a specific start in Indy.
we're gonna start on this day. Hopefully we end on this day or soon right around that same time on, and that will be the completion of our project.
A project is also something that's typically never been done before by either you, your organization in some cases, any other human being on Earth.
These are these are unique.
And what makes this career field so exciting is that they are unique. So every project that you try to manage or try to work on, especially the enterprise level projects, is gonna be the first time that you've probably had to face
this specific business problem. We're gonna know more details on that later, but just know that that there are a lot of unknown variables. This is a complicated topic and so don't be intimidated by all of the things that you don't know
that is normal in project in their product management. And there's ways that you can mitigate against those unknowns
which will discuss later on in the course.
So ah, project is also complicated enough
that it requires planning and execution. So what that means is, obviously, if you're
goingto take on a home project, a home repair project, you're gonna stand down your dining room table and repaint it. Okay, that's you can call it a project, and it means some of the other criterias
but generally speaking and doesn't require a lot of planning other than going to the hardware store and picking up your selection of paint.
If you were, however, going to completely redo your back deck, you can see where that would require much more planning and execution.
So some examples of what a project is's down below there, and we've discussed him at some length in the previous video.
One caveat. I will add. For those of you that are veterans or active duty military, a military mission
has almost 100% overlap
on a project.
So one of the things that I noticed when I joined the military after my I t product management time
as I was starting to rise up the ranks structure and leading missions. And, like, you know,
this seems an awful lot like my previous job. The only difference is I was doing military stuff as opposed to I t product management stuff.
So if you do have a significant military background, you can take heart in knowing that the terms might be different. But the process is gonna look very similar to what you're used to doing.
So Project management is complicated
or can be. Or is it?
there's certain universal truths that we can talk about within project management, and these will permeate throughout the entire course, and they're extremely important to understand.
So the first thing that we're going to do is we're gonna define the who, what, when, where and why. And that document is typically called a project charter, and we'll discuss the Project charter and much more detail in a later video.
We always want to make sure that when we're defining the who, what, when, where and why that we do not worry about the how that's the execution. That is what they call thinking through implementation. And we frown upon that, especially
in enterprise projects, because
you don't know what your work is going to look like at the end. You don't know necessarily how the organization is going to restructure. And if you tried to think that our implementation, especially if you try to keep the status quo
within your organization at the end of your enterprise project, you're often gonna run into some serious organizational change management issues.
And that just simply means that your organization will be unable to meet the needs of the enterprise project once it's complete.
Now, the part of this role that
I believe is very under emphasized in current project management doctrine
is the definition of the triple constraints. So you have a budget constraint, right? We don't have an infinite amount of money.
We have a schedule constraint. We have an infinite amount of time, and then we have the performance constraint which are basically what the thing that we're building is supposed to do at the end of it
often times, especially in large agencies, especially in government. Unfortunately,
the failure to address the triple constraints
causes a great deal of scope, creep, schedule, creep
and other negative side effects later on in the project. So the old rule of thumb is you can have it good, fast and cheap. Pick, too.
So if you're going to define
the driver, which is the least flexible constraint, So again, let's go back to our building. A house scenario.
I'm building a house
and I only have $200,000 not $201,000 not $200,000.75. I have $200,000. Exactly
that would then become the driver, most likely cause that's your least flexible constraint. So when around the money
project is over, whether I got the cool spot in the fancy kitchen or not,
and then you're weak constraint is the one that is generally the most flexible. So in my house example, let's say that I'm currently living in a different house, and I'm not really in a huge hurry like, Hey,
you can let the schedule slip. Not a big deal, but you can't spend any more money.
And that would kind of show you, uh, how you define the driver and we constraint. Now, why is this important.
The Project Manager
primary role is to manage expectations of the project sponsor on those constraints.
Get executive buy in on what the driver and the weak constrain our because that gives the project manager the flexibility to adjust accordingly when
delays and other things come up. Murphy's law is alive and well in project management, and your your project is almost never going to go from ideation to conclusion without there being some kind of challenge. Delay, cost overrun, et cetera.
If you don't have your sponsors by in ahead of time saying that, yes, I'm okay with pushing the schedule, but I do not want to spend any more money or I'm okay with not having all of my wish list performance constraints. But that's got to be on time, and it's gotta be on budget things of that nature. It makes it very difficult, if not impossible,
for the project manager to do their job, which is managed the project.
So once we have this thing called a project charter, and again, it Z,
the product of a project manager manager is cognitive in nature. Your expertise is not necessarily in doing any one thing it's in structuring the cognitive framework of project management and guiding your executive team and your project team
through this process. And then what you see on the screen in front of you
is generally Africa ble to almost any project.
Now, once you've decided on the who, what, when, where, why and we've structured
our project charter. We have our budget constraints, schedule, constraint, performance constraint. We have our driver and a wee constraint.
You now have a framework with which to actually manage the rest of your project. And that's when you figure out how to break down the work, a k a. How are we going to do this? We now know within a box very clearly what we're going to do. So let's figure out how to break down the work.
This is Ah, good graphic that I think illustrates the triple constraint, and you're gonna hear me repeat myself ad nauseum for the remainder of this course. But it's so important,
and I don't fully understand why it's not more prominent in doctrine.
you want something that's going to be low cost and high quality,
right, it's gonna take more time.
If you want something that's
low cost and done quickly. It's not gonna be of high quality,
so this is just kind of illustrating. I used to joke around with people that they don't call him the good idea of physics. They call him the Laws of Physics. Well, this is kind of the law Project management.
It is almost impossible, if not outright, impossible
to change the reality of the Iron Triangle. The triple constraints.
I've seen projects over 20 years now, and I have yet to see one succeed. That was low cost done quickly, end of high quality. It's just not doable.
you talk a little bit about project management and what that looks like. It will move on to what enterprise projects are
now. Enterprise projects are projects on steroids. There are
numerous project dependencies, and what a dependency refers to is a different part of the organization has to accomplish something before I can get X, y Z's a part of my project complete.
The more dependencies you have, the more complex the project becomes, the more difficult it is to manage. You also have numerous project constraints, meaning I can't affect the way purchasing orders their material
early on in the project because they have to be able to continue to do their normal business function for the next three years until my project is done.
There's a high level of risk in enterprise project management and a high level of complexity that's
almost always the norm
for enterprise level projects because the goal of an enterprise project is to bring about a large change to the organization.
A good example would be Amazon
in the late nineties, Amazon with an online bookstore,
you could order a book mail to your house. That's great.
That is not the Amazon that we see today. So at some point they made an enterprise wide effort, a very successful one, in my opinion,
to revolutionize logistics and just completely changed the way that we do online shopping.
Now I can order almost anything in the world and have it delivered to my front door within a couple of days. That is an enterprise wide shift in business strategy and organizational strategy
in marketing strategy and enterprise project management strategy.
In addition to that, they're continuing to evolve with some of their new stuff, like the elections and all that.
So they and then never mind Amazon Web storage so they're continuing to embrace and embark on.
He's very risky enterprise level projects, but when they're successful, they can be phenomenally successful and really change the way that the business is done by the organization.
So in summary,
we've defined the projects.
We've defined the triple constraint driver and we constraint,
and we've defined what enterprise projects are.
Thank you for your time, and I hope you'll join me again for the next installment of Enterprise Project Management.