6 hours 23 minutes
Hello and welcome back to Enterprise Project Management.
Less than 14. Enterprise project execution.
Uh, thanks again for taking this course and stick with me as we, uh, come toward the tail in here.
Um, in this lesson, what we're gonna talk about is just a general
project execution methodologies and challenges in best practices specific to an enterprise project. We know that they're more complicated or complex.
They have greater challenges because the organization is now involved. And you've got different division than bureaucracies and all that kind of stuff. So you're gonna find yourself in the position where
building those communications and keeping that communication and managing that communication are going to be more difficult
for your enterprise projects
so specific to
governance in some ways. But really, what you're talking about is is the organizational governance and the structure of the organization
that this project is being run out of. So if you're looking at more of your matrix organizations versus your traditional hierarchical organizations, you have
a better overall level of control as the project manager. But you do have some specific challenges. So first thing I want to talk about
is managing communication in the work flows. And again, this is specific to enterprise project execution. So some of these things will be less of an issue or definitely be less formalized when you're in a smaller scale project.
So the 1st 1 is what's called a racy matrix. Racy stands for responsible, accountable consulted and informed
and the idea behind a racing matrixes. When you're doing these enterprise projects that you identify as early as possible
all of the stakeholders within the organization
and for each task or sub task or group of tasks or whatever,
we should be able to identify
the stakeholders that are going to be responsible. And ideally, that's one per task.
Um, but the person responsible is obviously overall responsible for making sure that everything gets done.
The person is accountable, which is the A is usually the person that is actually
directly accountable for the work. So, in the case of, say, the project's schedule,
the product managers accountable to make sure the schedule is up to date and manage. But they aren't necessarily responsible because they may not have enough,
political power, really to modify the schedule. That's where your PSC comes into play if things start to fall behind or whatever the case might be
is somebody who is part of the approval chain for that sub item or task.
But they're not necessarily doing any work there, just that approval authority. So if that that task means approval of one or many levels within the organization than their consulted. And then finally, they informed, are all those stakeholders that are going to be interested
in the status, whether it was completed or not completed
on time and things like that.
But they aren't necessarily decision makers. Those of your subject matter experts, your developers. You want to keep your team informed, not drown them in communication. But you do want to keep them informed
and by identifying them as an eye under racy matrix. You'll kind of remind yourself and remember to inform them when you have different project task being completed,
that that sounds complicated. It is
so one of the other things that you want to look at is automated systems, so there are numerous automated systems that govern project management that are designed for these large, complicated, complex enterprise level projects and what those systems conducive for you
is automate the tasks that the project manager otherwise normally has to do. Now, can they automate your schedule now? Not really.
But if you have the right kind of system, once you build the schedule, then you can automate the notification to the appropriate stakeholders based on there, where they are in the racy matrix
that the task is beginning that is completed,
that has been delayed, whatever the case might be. So you wantto before you embark on an enterprise project you really want to look at, what are your organizational systems that you have for workflow?
And how can you automate the normal
minutia of project management? So I don't necessarily need to be manually informing people via email that they've been assigned a particular task in a project that's just gonna drag me down and really
caused me to have a lot of extra hours of work that doesn't benefit the organization. So if I have an automated system, which there are many that exists
whereby once I assigned a resource to a task they get in, an email on automated email says, Hey,
you've been assigned to build X y Z widget, Um, and used to be done by Friday except a reject er at for a postponement. They interact with the system that all I'm doing as the PM is looking at the macro level of how my resource is air are relating to the system.
As to whether my project is going is going well, we're not going well.
Another thing you might want to think about is building yourself a project wicky. So
the only diverse functionally, but they're also diverse geographically, so having some sort of central hub of knowledge like a project Wicky allows your project team members to collaborate in an a synchronous format
but allows everybody to get caught up to date. So these are some of the things that you know people don't often time to think about when they're doing enterprise projects. But managing that communication and workflow is really the primary
role of the project manager during product executions. How do you get the disparate pieces and parts of your project working together?
way that you evaluate your success, you want to tie those evaluations to both project and functional success. So these enterprise projects again there long
you're not gonna be able to stop your day to day work. We talked about the whole treading water versus swimming to shore kind of a thing.
So you really need to focus heavily on employee evaluations within these major organizations, especially that they measure both their success in the within the project team as well as their success in their functional area.
And ultimately, all this comes down to getting
your people, your individuals, those doing the work
to be to pull the same strategic direction as the enterprise project as well as the organization.
It sounds very simple. If it was that simple to implement that I would be a multi millionaire because I would be the greatest consultant in human history,
it's extremely difficult to pull off. There's so many variables I can't possibly talk about him during the class,
but you really want to focus a
a decent amount of your effort to make sure that you've got strategic alignment within the organization.
And then the last thing
forma best practices standpoint is just to decide during execution,
whether you're gonna lean, agile Orlean waterfall and we've done both types of schedules. Earlier on in the class So you should be somewhat familiar with the differences on. And that goes back to whether you are a wannabe utilizing a pool versus a push work system, pushing, being You're more waterfall
where you tell people what they're gonna do versus the pool where they can pull from state can ban board.
Um and they know what their workflow is. They know what they're kept capacity is, and so they can demand work at their at their pace.
You can use combine boards. You can do the more of a scrum methodology that involves a lot of stand up meetings. First thing in the morning
communicate heavily in person is ideal for scrum on your and your doing. Those either sprints is what is the term strictly for scrum.
Other folks will know what a federation, but they do kind of the same thing. If your time boxing your work and you're saying
I've got two weeks, three weeks, whatever to get many things done on my list is I can How money losing can I get done? So when you're using agile, just know that you're moving from a pole to a push type of system you're putting a lot more responsibility and trust in your project team,
but it also frees them up to work at a faster pace than you might
consider them working at, because nobody tends to work
in a vacuum on do extra stuff. So that way they can read, smacks efficiency without a lot of intervention by the project manager
and and really get a good solid workflow.
So in summary, we talked about some of the best practices in commonality with an enterprise project execution, focusing a lot on matrix organizations, which are pretty required for good enterprise project execution,
as well as the difference between agile versus waterfall in the execution phase and that member those air, not binary. That's a scale. So you can go hard core waterfall all the way too hard for agile. And there's lots of flavors in the middle.
Thanks again, and I will see you the next lesson