12.3 Enterprise Project Execution and Governance Part 3
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
6 hours 23 minutes
hello and welcome to part two of less than 12
on Enterprise Project Management Project execution in government governance.
We left off last time talking about the
composition of the PSC and specifically
projects you're in committee size as it relates to
the size of the project. And obviously, with Enterprise Project Management,
we know the size is gonna be a little bit larger than normal. So
we've done some research
on how big
the team needs to be
in order to work effectively. And we had talked a little bit last time about
using odd numbers instead of even numbers
in order to facilitate
the least amount of decisions being escalated to the E. S C or executive steering committee.
for the reason that their time.
So if the decision is too big for the PSC, if there's genuine
issues that prevent the PSC for making the decision, then sure escalated, that's that's the rule. That's why USC is there.
Well, you don't want to do is you don't want to escalate things simply because your six or eight member PSC voted in the vote with the time. So if you use odd numbers, you could help prevent that.
Um, and this is just a
obviously a recommendation of
the size of the PSC based on the size of the project. So
your large scale enterprise projects that air 10 plus $1,000,000 you're looking at,
ideally no more than nine people. When you get much past 12
it starts to become an issue where it's not really one group.
Research has indicated that if you get past 12 you end up with
two groups of six or a group of nine and three someone It's on,
but the group becomes too big to coalesce as a single unit. And the last thing that you want in your project steering committee is to develop clicks and
Groupon group issues. And so you want. Oh, really? Try to make sure that your group
is big enough to represent
the various diverse interests of the Enterprise Project team,
but at the same token doesn't become so big
that it becomes unwieldy. So that's why I use this chart as kind of a good rule of thumb based on the size of the project.
Obviously, money usually indicates complexity, although not necessarily
so. All these rule of thumb or that the exception that proves the rule. So there's exceptions for all of this. But what we're trying to do is come up with some good best practices that will allow you to plan ahead during the project execution phase and build your projects during committee. Um,
So that's kind of a little bit carryover from the last video. In addition,
you're S C as well as your PSC need to meet regularly.
I know that sounds very common sense, but you would be surprised at how many folks, especially in your senior leadership,
try to avoid extra meetings. And I don't blame them. But
you'll have sort of, ah,
a neglect through no fault of any one individual per se
but neglect nevertheless, because you don't have that consistent feedback loop built in so early on in the project. Hopefully during planning phase or maybe even during the charter phase initiation,
you build your PSC. The P S. C is meeting regularly. They get used to it. It just becomes part of their daily routine of life,
and you don't have those kind of problems, but you definitely want to meet at least monthly
at both E e S E and P S C level. The most common configuration that I've seen
the PSC meets every two weeks and the E S C meets monthly. So and we'll talk more about the roles and duties of the PSC, and you'll understand why that is. But
by creating at least one meeting for the E. S C for every two meetings of the PSC, you kind of cut down on the meeting fatigue of those senior executives. And remember from the earlier video you're PSC has got blinders on. They're focused on the project.
That's all they really care about. They don't have to worry about the enterprise. They don't have to worry about what's best for the business and all that,
so they can be more tactically focused. Even though it's a strategic and enterprise level project,
they're tactically focused on the project execution.
Um, the PSC also should
set the minimum qualifications for the project manager.
Now, let me explain this because I have ah experience in both government as well as private sector
rolls, very whether somebody is a contract that employees hired for simply the duration of the project, which is pretty common in government
or a full time employee of the organization that's been tasked with being the project manager for this enterprise project.
What is that issue here is
Usually the project manager is going well
functional organization. The project manager is going to report to one of two people
or one of two groups. Either they're going to report to
the PSC because the PSC is that the product managers boss and they're the ones that have to be happy with the project managers performance because they're the first line supervisors.
the project manager reports to the Project management office. So if the organization decides
we're gonna centralize this thing called Project Management into the product management office or the E. P. M. O.
In that, P M may report directly to that group or individual based on the rules of the organization. Now
we'll talk about this a little bit more detail later on.
But if you assume that the person or group of people
within the organization
that is the expert in this thing we call project management
is going to have a role on the PSC,
then it makes sense to say Well, okay,
the PSC is the one group of people that is tactically charged with decision making authority to ensure project success. They should have a role in a hand and choosing the person that's best suited to provide them a successful project
as well as indicate early on in the project to the PM themselves
we are your boss. So it creates a good level of accountability, and we'll talk about organizational tension later on. Help with that, too.
But what you're really trying to do is you're trying to empower that PSC because they are the first line of defense against project failure as much as the project manager may
cry wolf for, you know, whatever, trying to get some organizational assets behind them to help them fix an issue or a problem. The reality is, is that the PSC is the one with the real political power to enforce some of those changes. So
if you set in process early on
that the PSC interviews and hires the project manager either internally or externally through the use of a contractor, a vendor, then you're you're preparing yourself for success early because that PSC or the product manager knows that the PSC hired them and that their directly rip
portable to the PSC,
and they're gonna take that PSC very, very seriously.