3.2 Project Charter Part 2

00:02

hello and welcome back to the second generation of our project Charter Practical exercise.

00:08

This is cane, and this is the Enterprise Project management course.

00:13

So let's get right to it. We talked about the first section in the previous video, and we're gonna go ahead and move into the progressive elaboration of the performance requirements. And again because my driver is performance, I want to make sure that within my charter,

00:31

I properly gather exactly what the expectations of the customer are.

00:35

In this case, the customer is fairly technical again. We're a software company, so it would make sense that our customers are fairly technical. And so what we want to do is de compile their strategic objective of having this maze game into smaller, digestible chunks that I can then take back to the programming team

00:55

and actually get it built

00:57

and meet the requirements from the performance

01:00

requirement area.

01:03

So I talk a little bit here about some development methodology, but all it's really saying here is that within this project charter,

01:11

you're going to see exactly how I planned at a high level to do the business process analysis in the development methodology to support the requirements,

01:23

and that's really a serious of flow charts, which will go into more detail here, as as we progress through the charter.

01:30

But it's saying, you know that in this this phase we're generating maps and flow diagrams, and it may not be in the charter all the time. It really just depends on the organization, or they may be,

01:42

and we'll do a lot more in depth business process analysis later on. But this is a good little intro to kind of see how it's done.

01:49

So once we have the high level process maps, then we hope we generate drill down process maps, and those I won't should show you today. But that's too much detail. But basically that's like yours here, pseudo code or other types of process maps that you shouldn't have detailed enough

02:07

to hand to a programmer with the minimum of explanation and have a reasonably good expectation that they're going to be able to deliver that program.

02:17

So, using certain higher level programming tools like like fourth gen languages, it may be more general because again, you don't necessarily care exactly how the details are. And if it's a more technical type project than you may have more details there.

02:35

The

02:36

the main thing that I would put in the charter here is again once the client approves that high level process map,

02:43

then we start working on the sections that we just make sure that at that point we want to minimize or eliminate changes to the process map.

02:52

Because

02:53

at the longer you wait to make your changes. Of course, the more expensive and time consuming those changes are. I have a really good friend of mine who is a construction project manager, And, uh,

03:04

one of the funny things that he told me was he would tell clients often that basically, if I have to break out the concrete saw for your change, it's going to be very expensive. And I think we can all visualize that and realize that, yes, if you're breaking concrete on an existing building that you've already built and poured the concrete on that, that's gonna get pricey.

03:23

So it's kind of the same mind. Yet the longer we wait

03:25

to make our change, the more expensive it's gonna be.

03:29

And again,

03:30

the more up front you can be with this type of information,

03:35

the better off you're gonna be on the project manager.

03:38

So then we talk about some team assignments, and in this case, you know, I've got

03:43

a core group of folks that are developing the overall game

03:46

playing. I've got a core group of folks that are gonna be developing the Windows loader, the window shell that this game is gonna live in. And then I've got a group of developers that are going to be developing the graphics model. So I'm just showing here at a high level who the players are and

04:02

that way when it's approved and signed by

04:06

the Project sponsor,

04:10

I've got implicit by in that these folks will be able to come and work on the project, and we'll talk about organizational structure and later course, which will have a great impact on exactly how much

04:21

quote unquote force of law this type of thing has. But it's a good idea to put it in your charter, if you can.

04:29

In the next section, we talk about deliver bulls and

04:32

a lot of folks in project management try to manage toward the work.

04:36

The schedule and my head is scheduled. My behind Treadwell those are all good things and you have to know what those things are.

04:44

What?

04:46

It doesn't matter if you don't deliver the things that you're supposed to deliver to the customer or to the user.

04:54

So there's a whole school of thought on delivery Bols based Project Management, which is basically the idea that I really don't care how you do it as long as you deliver me these things.

05:04

And I don't necessarily recommend that as a strategy for enterprise project management.

05:10

But it's something to think about that you've got requirements, delivery, bols tasks,

05:15

these air, just units of work

05:17

and how you want to measure your project. Progress is gonna be dependent upon

05:24

what units of work are important to you. So a lot of folks that outsource projects to external vendors,

05:30

they tend to focus more on the delivery bols model because they don't necessarily care how many hours it took. I agree to pay you x number of dollars for this delivery ble. So here we've got a project charter and a signature block for that.

05:43

The program models Signature block for that, the U I sample beta sample and in the final program

05:49

At this point,

05:50

I would want to get, if at all possible, the project sponsored to go ahead and sign and approved. The project that may or may not be possible depends again on how much detail

06:01

the project sponsor wants to see. And then the project manager would sign the charter as well, making it a political, legally binding contract. It's not really, but just kind of pretend

06:14

some of some of them are, but they're actually called contracts.

06:15

So

06:16

okay, so I've got this kind of high level idea

06:20

of what the

06:21

Project Charter is going to talk about.

06:26

But because my driver is my performance constraints, I want to get into a little bit more detail on exactly how this process is going to work.

06:36

So I've made some process diagrams, and you can look at the use in more detail

06:41

on your own. But basically it shows from, you know, top left to bottom, right? What's gonna happen in the main section of the program?

06:50

So I've got to create the window, load the graphics load the maps,

06:56

create the lookup tables for the trigonometry that's going to determine based on where they move, what they see,

07:02

I have to be able to play a game.

07:05

I have to initiate a network socket, shut down a network socket.

07:10

I need to be able to initiate a drawing environment.

07:14

Initiate the mouse operations, actually have the different drawing events take place.

07:20

I've got

07:24

start the background music and be able to stop the background music parts, the commands

07:29

and look for specific command line parameters and then write stuff to log files. That's just building

07:34

the shell or the outer layer of this maze game.

07:40

And then I'm gonna get into the actual game play and you'll see here Same thing top left to bottom, right? Once they start playing a game, I'm going to start the game timer. I'm gonna do a Ray cast, which is just gonna paint the screen with both the user sees.

07:54

I'm gonna read whatever their mouths movement is or keyboard movement based on what that movement is. I'm gonna move the player

08:01

If they decided to shoot an energy blast. I'm gonna do the energy blast

08:05

that I'm going to load the screen with the new image.

08:09

I gotta be ableto receive and send that message is here. Send beeps

08:15

and so on. So this is again just showing

08:18

the structure of the maze game and how I'm going to build these modules of code.

08:24

This is different than a true process model, which I'm gonna skip the Windows one because I'm running short on time and go straight to the gameplay. So the idea is,

08:35

I have built a process model that is supposed to inform both the user of how the game is going to be played, or the customer as well as in for my programmers on how they actually have to build the game.

08:48

So you will see here a couple of, if then loops kind of thing. So I start my game timer

08:54

is the game over? If not, I'm gonna cast a new ray.

08:58

If it is over, I'm gonna split the screen

09:01

and show them that their game is over.

09:03

Once I cast that array, it shows him that image I'm gonna process there either the keys, stroke or their mouth stroke

09:11

any network images or messages rather than get sent during the intermediary time. I'm gonna process those as well if they have. If the keyboard stroke initiates the energy blast, I'm gonna an animate the interview blast.

09:24

And if not, I'm not. And I'm gonna go right back up here to the top and continue down that road.

09:33

And then if you see here

09:35

in that key value and mouse value and get message value, which were all these high level ones right here,

09:41

I then drill down further.

09:43

So once I processed a keystroke, I make sure it's valid. If not, I send a beep.

09:48

If it is valid, is it movement?

09:52

If it's movement, I get the direction and go ahead and process the movement in distance. If it's not a movement, is it a blast? If it is, I run a blast in command.

10:01

It's not a movement or a blast, is it? Eh?

10:03

Net message. If it is, I send it to the other user.

10:07

So we're just decomp piling in layers to get to the point where I can give this to a technical professional and have them understand how to actually write the program code. Based on these continually, these continual layers I'm getting Maur and more detail as each layer progresses.

10:26

And then finally, I've got a U I sample cause, remember, that's one of my deliverables. So I've developed this little you. I sample this is gonna go to the customer along with everything else, and hopefully they'll look at it and say Yes, this all makes sense. I agree that this is the best way to go about solving this business problem.

10:46

And then, of course, it talks about screen controls and stuff at the end.

10:48

But the basic premise here is to understand that

10:54

I've got to get my customer or my user enough details to make a decision on whether or not this project is a good investment.

11:03

Not necessarily that I need to give this, as is to the programmers.

11:07

But if you're requester is technical in your

11:11

users or technical your project manager or your project charter is gonna be more technical if they're more financial,

11:18

the same charter would look a lot different. It would be more about profits and losses and our lives and everything else because they're more financially minded. So it just really depends on what the customers looking for. But that's a relatively good sample of a

11:33

fairly easy

11:35

project charter that'll give you at least an opportunity. Look at one if you have not done so before.

11:43

So, in summary over these last two videos,

11:46

we've focused on the tail end of the initiation part of the Project Life cycle. And we've looked at a project charter in detail.

11:54

Thank you very much for your time. And I hope you'll join me for the next lesson.