5.2 Project Execution and Closure Part 2

00:00

one of the biggest challenges of enterprise. All projects, really, but enterprise projects, especially

00:06

when you are doing your project planning. The reality is you don't know what you don't know as you get into execution and start actually

00:15

building and testing and doing these kinds of things, you're may find yourself having a large amount of changes, some

00:23

our changes to capture an opportunity that might save costs, save time, whatever. And some changes are just based on a reflection that this is more difficult or more complicated than we initially thought

00:34

so again is part of your project planning. You do your change management plan, and you really want to make sure that you execute and control that change as it's occurring as close to real time as possible. And don't let change get ahead of you. We'll talk a little bit later on in the course about organizational tension.

00:53

But just because the changes proposed by

00:57

a member of the governance board, a member of the PSC, a member of your user community, whatever,

01:03

it doesn't necessarily mean that that change is appropriate for the project. Projects tend to draw out almost in phen item.

01:11

If change control gets gets to, uh,

01:15

gets to rigorous or too out of control scope. Creep happens and you end up with a much bigger thing than you initially had. So you do have to ask yourself and ask the governance board when they're approving changes.

01:26

Can this change be delayed Rite Infamous Phase two are infamous enhancement cycle. One or whatever you wanna call it is like, Hey, this is a great idea. It's at a scope for the project. Let's get the project complete, and then we will address these as enhancements to the system

01:44

later on down the road. One of the things to remember is

01:48

as a rule of thumb,

01:51

80% of your system cost is gonna be in maintenance and enhancement cycles. And really only 20% is in the project that actually stood up the system. So don't be afraid to say, Hey, look, we're gonna be living with this thing for years, maybe decades.

02:05

We're gonna have to enhance the system. We're going to make it better. We're gonna have continuous improvement. It's just not a good idea necessarily to stick it in the project today because of whatever various reasons and then that just becomes part of your enhancement cycles.

02:19

The next thing is, we talk about measuring progress, and we talked about managing the turn and task completion The things of that nature and that is a very good way toe measure projects. There's nothing inherently wrong with it.

02:30

But there are multiple ways to really wrap up and get your arms around what your project progress is. You've got kind of three areas that I'd like to call him the delivery bols area, the Tass area and the requirements area. So

02:45

if you're doing the Liberals based project management, and this normally occurs when you outsource a lot of stuff and and you really don't care

02:53

how the sausage is being made, per se is longing for delivery bols air being turned in on time and being approved by the customer or the business user thin? Great. If I've got 10 deliverables and to whom have been turned in, I'm 20% down with my project.

03:07

How many hours did it take? You don't really matter. I'm I'm on a fixed price contract. Whatever.

03:12

If I've got a year to do it and I've got 10 deliverables and I'm six months in that I've got five deliverables turned in. I'm on schedule. Great. I've only got three deliverables turned in. I appear to be behind schedule, so I'm not tracking the hours. I'm not tracking the effort. I'm really just tracking. What are the tangible things that we determined

03:30

that that this project was gonna produce and when are they gonna be produced?

03:35

And am I getting those tangible things? That's kind of one method for managing an enterprise project that becomes a little bit less effort intensive for the PM

03:45

And I wouldn't recommend doing that for Internal Project, necessarily.

03:50

Just because it's

03:51

doesn't really work quite effectively. But if you have a vendor or a consultant company or whatever, that's doing majority of the work.

04:00

And if they've gotta put folks on overtime 80 hours a week or go to three shifts a day or whatever not your problem. You're you're You signed the contract based on this delivery ble being turned in on this date. And that's how you're gonna manage your project. That's one way to look at it.

04:15

Tax we talked about with managing the term. You're measuring progress based on here's the number of tasks that were complete. Here's the number of tasks yet to be done. Here's how long the tasks are supposed to take. Here's how long they're actually taking someone so on. And so you can kind of measure your

04:31

performance, schedule, performance or cost performance based on in my own schedule on budget. So on.

04:38

And that's great for internal projects because you have the level of resource visibility hopefully within your own organisation. That's high enough that you can see that Oh, poor Bob is working 90 hours a week to try and get these task done. We should probably resource level that so that we don't burn out our resource,

04:57

whereas if it's a vendor nine times out of 10 you won't get that level of visibility because that's not really part of The contractor will relationship, So that's kind of their own problem to deal with. All you really care about is are you getting your stuff?

05:10

Requirements is kind of

05:12

the same thing is deliver bols, except where a requirement reflects is a certain thing. The system must do acts the system must

05:20

do. Why I must be able to log in with my network log in or whatever. It's just it's just a list of requirements that when this thing is done and given to me, here's the things that it must do. So you're not getting deliver, Bols in the sense that you're being handed,

05:35

physical, tangible things that are being complete.

05:39

But rather than

05:41

de compiled those requirements into tasks, you can still manage that project at the requirement level because they can't take that requirement. Break it down into the lower levels if they want. This is by they. I mean, like a vendor or third party,

05:55

um, or not of his internal whatever. But again, you're asking the question of your project team. How close are is our system to meeting this requirement? And if the answer is it's done, it means this requirement. Check the block and you could look at your progress. It doesn't meet the requirement yet

06:15

you don't check the block so again, going back to that binary thing either does or doesn't meet the requirement

06:19

within the project plan or the requirements, traceability, matrix or whatever document lists these requirements.

06:26

So again, from an enterprise project management standpoint,

06:30

when you've got hundreds and thousands of task hundreds of requirements, potentially thousands of people working on this project.

06:39

You can kind of make it a little bit easier to manage and make it a little bit clear to the project manager and the project Governance and the executives by saying, Hey,

06:47

this project created 100 requirements

06:50

To date, we've completed 50 of those requirements. We have 50 left to go.

06:57

This is a one year project or six months in, so we're more or less on schedule. We're completing the requirements

07:03

according to our objectives and our goal.

07:08

Contract management sort of ties into a lot of that measuring progress. You may

07:14

not even know who your vendor is going to be

07:16

until you get in fairly deep into the project. And this is very common with, like state and federal government agencies because of all the contract management rules, you have to do your requirements document, do your statement of work to do all this kind of stuff and then put that kind that bit out on the street and wait to get get those

07:35

bids back and then do your analysis and then picking a vendor so you might be fairly deep into execution. before you actually have that contract.

07:44

So you want to make sure, Of course, the contract reflects the requirements and deliverables that Aaron your project plan. But there is a contract management aspect to project execution rather than project planning, because you usually are done planning before you go ask for the money,

08:01

get approved for the money, and then you can go selective vendors. That's kind of how that normally works, especially within government.

08:07

So you want to look at things like, Does my contract statement of work match with the requirements that might my project has with the delivery bols that my project has? Because the vendor that you that you are selecting for this contract

08:22

doesn't necessarily care that you have these these particular requirements. What they care about is what are they contractually obligated to provide, And that's usually in the statement of work.

08:33

The last area want to talk about last two years I want to talk about is testing and training.

08:41

They are normally occurred very late in the project. You've completed the thing that you think that the customer wants you hand to the customer and say, Hey, test this and tell me if you like it, if they don't give it back to you and you fix it. That's called regression testing.

08:54

And then, of course, the training on the new system.

08:56

The problem is, with these two parts of product execution, is there the tail end

09:03

and they're the most often short changed.

09:07

So you really have to spend a lot of time and effort educating your project governing this team and educating your executive leadership on the importance of both testing and training.

09:20

It does no good to bring a system live when the user's I know how it works. It does no good to bring a system live when there's a lot of critical errors to the system. It's just going to cause a lot of heartache, and resistance to change is gonna increase because they gave me this new thing and doesn't work at all.

09:41

So going back to the business analysis part

09:43

if your subject matter, experts on this particular business process

09:48

are running ahead of schedule behind schedule. But whatever you need to look downstream at your testing and training and realize that whatever challenges that you face at the beginning of the project with People's resource availability is most likely gonna also occur

10:05

later on down the road. So don't short change your testing and training. Make sure that you do

10:11

your utmost to

10:13

modify the schedule as needed for to maintain the highest level of testing and training. That's possible. And then the final area is organizational change management, which I'm not going to get into in a great amount of detail, because there's literally been thousands of gallons of ink spilled over the years talking about O. C M.

10:33

But just know that it exists. It is a very big deal. You cannot take a system and replace it with the new system and not expect there to be a pretty major oh CME effort underway. Make sure that you talked to your senior leadership and see if they already have an O. C. M.

10:52

Team or division.

10:54

And if they do that's great.

10:58

Engage them early on, use them at whatever level that they're willing to help you and really make sure that you're getting the information and the processes and the changes and that communication coming from the O. C. M folks. They're the experts at it.