Crafting a Comprehensive Project Charter for Successful Execution

Once you have identified projects that you want to move forward with, you may consider writing a project charter. Now, not every project requires a charter, but the more people are involved, the more important the project, the longer it's going to be. If people need approval, we want to get everybody on the same page, a project charter can help us to agree upon what this project is all about and to move forward with it.

So what it is, is it's a document describing and kind of forming the foundation of what this project is all about. When you think about projects that last a long time, the sponsor who originally said, let's go ahead and move forward with this project, they might retire, they might get promoted, leave the company before the end of the project. You as a project manager, if you are working on a project and you switch to another project, you might hand that off to another project manager.

So somebody else, whether it's a sponsor or a project manager, might need to take over the project. And one of the ways that makes that easier is if you have a project charter describing what this project is all about. So it's kind of snapshotting at the beginning of a project, what are the goals, what are the deliverables, and exactly what's going on with this project.

I'm going to go through what we put into a project charter and give you some examples of this, of course. Another thing that you can also do is look at past projects in your company. See if they have examples of charters that have already been written.

That can be a good starting point, or you can go with what I'm going to show you next. Now, I know you're not going to be reading this here on this particular slide, but this is just a very zoomed out view of a two page project charter. This one is just very basically formatted.

It's not especially pretty. You can make these fancier if you want to, but it's mostly what we're saying in the project charter that is most important. So let's go through these different sections because I know you can't really read this on screen.

That's not designed for that. So first, I want to go through at a high level what kind of things we put in, and then I'll show you an example and we'll walk through a project charter. So of course, you put in a title and I like kind of visionary titles, but basically just put some sort of title to the project and you say the purpose.

So what is the need? What is the justification for why are we doing the project? And one of the reasons why you lead with the purpose is if you lead with kind of things like the cost, for example, that might be kind of shocking to somebody. But if you start with why we're doing this, then something like the cost to justify the spend based on why this is needed is a little bit easier to kind of swallow per se. So why are we doing this project? And we can describe kind of on a high level, the most important steps.

This is an overall description. Again, right now I'm going to give a high level overview, and then we're going to dive into examples of these. We give the objective, which is basically the iron triangle or triple constraints.

This is what is the end product? What are the deliverables? And we're going to talk about them in terms of the scope or expected benefits, the date that we're going to complete it by. So that's the time part and the budget or the cost. What do we think we're going to spend on this? So time, cost, and scope.

We also want to go into what does success look like? What is the outcome? Set that vision of, yes, there's this problem, this need, and this is what success looks like. If there's anything about funding that you need to talk about in particular, I know we laid out a budget, but if there's anything else we need to say about funding, we can put that in here as well. Major deliverables, what are the tangible or intangible end products? What are those deliverables that we're going to be producing? And acceptance criteria.

By what standard, by what criteria are we going to evaluate those deliverables to say whether they meet our criteria of what is success? So I mentioned this in an earlier video that it's not just enough to produce deliverables, but those deliverables must meet the requirements for us to achieve success. That is how we truly achieve success. So for example, let's say a company is producing underground electrical wires, and they need to make sure that those wires are good enough to last for the warranty period, and they need to not just produce the wires, but they need to make sure that they are good enough quality.

They're going to need to be some sort of electrical rating and quality. They need to make sure that there's standards that are met. So do they just produce the deliverables? Do they just produce the metal wiring and then hand it over to kind of towns and so forth to install? Or are they going to test it? Are they going to maybe build some testing equipment, testing facility, and then run electricity through it? And maybe they run electricity through it until it explodes to see what are the limits, what are the ratings that we can do to make sure that we know that these wires are capable of accepting a certain amount of electricity up to a certain rating, and that we can stand behind that product.

And then as they're getting more and more metals from different manufacturers producing additional wiring, that would be something they'd have to do on a continuous basis to make sure that the wiring that they continue to produce is meeting the standards, right? They cannot just produce the deliverables. They must continue to make sure that those produced products are acceptable, that they are good things. So how do we rate those things? That is acceptance criteria.

So at this point, we are still in the initiation phase. We have not fully gone into planning, but we might have some sort of idea of milestones, of target dates that we hope to achieve for certain key events. Now as we move into planning, we'll see if those things are fully achievable, but probably at the start of a project, we're probably going to want to try to hit certain targets.

And so we could list those milestone schedules that we hope to achieve. Any key assumptions? If there are assumptions that we have made, rationale behind the scenes, ways that we've justified certain things, we should make sure that we explain those things so that other people know about any assumptions that we have made that is clear, so that we're not all just thinking about different things and coming with our own assumptions. We want to make those assumptions clear and written out.

Are there any constraints? Any restrictions that need to be considered? Things that are unchangeable, right? Constraints are things that we are bound by. And so some things you might think, like for example, you might assume that things like budget or scheduling are constraints, which sometimes they are. But sometimes for some projects, it's something that we want to do at some point, but some projects are much more flexible.

Maybe there's other priorities that will take precedence, and we don't want this project to push out other projects because it's of less importance. So maybe things like the deadline can slip. It might not be a constraint.

Other things, like if you're going to have a holiday party, the constraint is you got to have the holiday party by a certain date because otherwise you're past the holiday. So every project has some things that they can't give on, that they must achieve, and we want to make sure that those constraints are clear. Are there any major risks going into this project? We don't always know major risks going into something, but if we do, we should make sure we disclose those because if the person signing off on this is not made aware of those risks, then they might come back later and say, you knew about this risk and you didn't disclose it.

You didn't tell me about this. That might have changed my mind about sponsoring this or a client be willing to move forward. So we want to make sure we disclose those major risks should we know about them.

Approval requirements. So within the project, who has approval authority over various things? We want to think about things like who's going to be the project manager, what kind of reporting are we going to do? So how often do we want reports? What's going to be the content in those status reports? Who do those status reports go to? So for example, your people in your team could be reporting to you as a project manager, but also you reporting to your sponsor or client. What kind of reporting are we going to do? And the hope here is that we then get approval and they would sign and date this.

And this is something that before it gets approved, we might have to revise this. And the idea of this is that we want to kind of literally get everybody on the same page, so to speak, where if we write this up and somebody looks at this and says, oh no, we should be doing this or this thing's wrong, or let's change this. It's a way that everybody can look at something and say, this is what we all agree to.

So we make sure that we didn't hear the wrong things or think the wrong things and that we can all move forward based on this approval. So what we're going to do here is take a look at examples of this. And in this scenario here is XYZ corporation.

We thought a long time about that company name there. XYZ corporation wants to throw their first ever holiday party for its 40 employees. So it's a small company.

It's just got 40 employees and they've never done a holiday party. So they want to hold a holiday party. They think that each employee is expected to bring just one guest.

That's an assumption that they're making. The party will be in two months and consist of appetizers, a dinner buffet, and a dessert. And the intent of the party is to show appreciation to their employees and recognize certain colleagues that are, they've been doing some outstanding work.

They budgeted $15,000 and also this is a fictitious project here. So if you think that's too much or too little, don't make judgments about that. That's just a fictitious project here just for an example.

$15,000 has been budgeted and Jonathan Reed is going to be the project manager. Marketing, because it's a small company, marketing is going to handle some of the internal news, announcing it, trying to get people to come there with the motivation. And HR, some people there are going to help handle some of the party details.

So they're going to kick in. So people from across different departments are all going to kind of work together because it's a small company. And the idea of this was by the president or CEO, they're the sponsor.

They're the ones that came up with the idea and they want 90% of the people to attend because they're like, well, you know, we're a small company. We really want most of the people to come here. We're not going to do all this work and then not have people come.

So that's to them, success looks like most of the people attending. And they also want to make sure that people have a good time, that this was worthy of doing. So they want to learn from this.

And you know, they've never done this before. It's the first time. So they want to do an anonymous survey after the party, just to kind of get people's feedback and see what they thought about it.

So in writing up a project charter for this, we can put a title on it. XYZ corporate holiday celebration of our employees. Then a purpose.

Why are we doing this? We want to hold the company party to show appreciation to employees and to provide recognition to outstanding team members. So that is why we are doing this project. And then also the party is going to consist of appetizers, a dinner buffet and dessert over a period of four hours.

So the purpose is kind of saying very briefly, like this is what the thing is, and this is why we're doing it. Now the description can go into more details. So I'm not going to read through all of this.

If you want to in the slides, or you can pause this right now, you can read this yourself, but basically it just goes into more details. This is not necessarily a formula that you would write yourself mimicking this text here. Obviously it would be dependent on your particular project.

You go into a bigger description here. The purpose is meant to be kind of short and to the point, and then this gives additional details that we can discuss. Now the objective kind of summarizes things again.

It says the iron triangle scope. What are we doing? We are going to research, plan and execute a for 80 people. That's the scope.

What's the time in eight weeks? What's the budget within a budget of 15,000? So very succinctly put, this is what we're doing. This is how long it's going to take, and this is how much it costs. It does not get into the purpose or the why, because that's already been explained.

Success criteria. What does success look like? The successful execution of this party is expected to boost employee morale and motivation, as well as form stronger relationships amongst co-workers. That is setting the vision of what success is, which helps to give people the idea of why we're doing this as well, but looks at it from a different perspective than the purpose.

This is setting the vision for success. If there's any notes about funding, in this case we already said that it was going to be 15,000. So when we think about the formula for a project charter, it's a bit of a template, but you don't have to put in all of the sections.

For example, if there are no major risks, then there's nothing to say for risks. If there's nothing additional to say for funding, we might not have to include this, if that's already been stated in the objective. In this case, there's nothing really else to say, so it's kind of rehashing what we've already said in the objective.

So a section like this might not be necessary. If there's anything additional to say, for example, sometimes government projects can only go over by a certain amount, so that might need to be specified to say the budget for something that we come up with can only go over by 10%. So that might be an important thing to say.

What are the deliverables? Obviously a holiday party. That's one of the things we're delivering, but that's just kind of the most obvious thing. When you think about the purpose, the purpose wasn't to throw a holiday party.

It was we're holding a holiday party to do something else. So when we think about deliverables, they are not just tangible, but they can be also intangible. Really, the main deliverable is employees must have an enjoyable feeling, feel appreciated, have a more positive feeling about working at the company.

That is truly why we're doing this project, and the holiday party just happens to be the vehicle through which we are trying to do that. Also, secondarily, not the main reason we're doing it, but also they've never done a holiday party before. So they're also going to form relationships with local vendors if they ever want to do things like catering and parties in the future, maybe with clients.

This can be a good way to kind of practice this in an internal way, and then maybe they do this externally with outside clients. So that's kind of a secondary bonus that, hey, we're also getting practice doing these parties, which we might need to do in the future for other clients, but it's not the main reason. The main reason is for employees.

Acceptance criteria. So how do we judge whether this was a success or not? And I like the idea of thinking about acceptance criteria, because a lot of times people just think, well, we're just going to do something, and they don't think about measuring success. So in this case, the CEO wants 90% of people to attend.

So success looks like 36 out of the 40 employees coming, and they want to do a post evaluation. So they want to get an 85% or 4.25 out of five. That will be to the CEO a successful evening holiday party if they achieve that evaluation score and that many people come.

Otherwise, if they get too few people coming or they don't get a good enough evaluation, then they won't feel like it's the success that they were hoping for. So it's a good way to think about, if let's say, for example, with another project idea here, if you were redesigning a website, what's the purpose of the redesign? Are you trying to get more conversions? Are you trying to attract more new customers? How are you measuring that? What is your acceptance criteria? Are you trying to get 10 new customers? Trying to get 10,000? Are you trying to get a million new customers? These are wildly different things. So let's quantify that.

And also, let's think about tracking that, because as part of the project, it's not just doing the redesign. It would be doing the redesign and then tracking what happens with that redesign. So for example, I was training a famous company.

I'm not going to name names here, but they were selling a product and it was a DVD of a video. And when people would come, they would buy this DVD. It was a very popular product that they were selling on their website.

And they thought, well, we want to sell even more of these DVDs. And so they made a video and they put that video so that people could watch the video. And at the end of the video, they could or at any point they could just scroll down and buy this DVD.

The problem was that after doing this intro video, they thought, hey, this was great. They posted that video and 90% of their sales disappeared instantly. People just weren't buying it.

And they tracked it for a few days. And after a few days, they pulled the video, sales went right back up. And what they realized is that the people coming didn't want to watch the video.

They just wanted to buy the DVD. That's all they wanted to do. And so by putting that video, they thought they would enhance sales, but they actually made them worse.

Their project was to make the video to sell more and more DVDs. Unfortunately, it backfired and actually lost them sales. So remember what I say, don't assume success.

If they were not tracking it, imagine they do this thing and they're so proud, they post it and they walk away and they don't look at their sales. And later, eventually, when they look at them, then they would see, oh my goodness, we lost so many sales. So we must think about tracking that performance.

And also as a company within a company with internal projects or for external clients, if you are tracking the outcomes of your projects and you're saying this is a quantifiable way to measure success, those could be statistics that you could use to justify either other projects or to talk about with clients to get new clients. Like we did this redesign and we increased sales by a hundred percent or whatever it is. So if you're tracking those things, those could be ways to attract new business or justify certain things.

So it can be a way to hold people accountable and make sure that what we're trying to do is what we're actually doing. So it helps you also to kind of better plan. And also there's going to be time involved in tracking those things and, and some budget as well.

So those are all part of the project. The project doesn't necessarily end when let's say a website redesign launches let's track it afterwards. So milestone schedule at this point, we have not done all the planning for this yet, but there's certain milestones that we think we would probably likely hit based on the kind of amount of time between now and the holiday party, getting things like the initial party invite sent, getting a headcount, finalizing our list of employees that we want to you know, all of these kinds of things are kind of major milestones that we think we'd probably try to hit later.

We'll do all the final planning and this might be subject to change, but going in, this is what we think our major milestones would kind of be. Are there any assumptions? Well, in this case, because this is our first holiday party, we don't have any historical company data or experience to fall back upon. Like, I don't want you to think, make some sort of assumption that we know what we're doing here because we've never done this holiday party before.

So don't make that assumption. Also, I would put in here, although it's not in the slide, I would also add that an assumption is that each person will bring one guest. I think that's an important assumption to make because somebody reading this document might say, oh no, we think people will bring two guests and that might change the budget on something.

So I think that would be a great addition that we could add to this. Constraints, things that are unchangeable. Well, the party must occur on the agreed upon date.

It's a holiday party. Got to do it on that date. And because we have to make reservations for one thing, but it's also a holiday party.

So we're going to sign on a date, do it on that date. Also, very importantly, this is employee centric. So the most important thing is employee enjoyment.

We are trying to get our employees to have a good time. And if we're doing things that are sacrificing on that, and ultimately we're holding up a holiday party, but people are not having a good time, then the whole goal, the success of this project is, you know, we're giving up on that. So we want to make sure that we are focusing on employee enjoyment first and foremost.

That's a constraint. We cannot give on that or else why do the project any major risks? In this case, we don't think there's, I wouldn't say there's really any necessary major risks going into this. But you know, this is one that's maybe, maybe somebody thinks that this is a major risk.

It depends on the company, low pre-event employee motivation. Maybe people don't really want to go. If that's put on here, then somebody thinks that this is a major risk.

Now that depends. You'd have to know your company, right? Don't make up risks, though. The idea, let's say this is just filled in just so there is a risk.

If you don't think that this is a major risk, you know, yeah, maybe it'll happen, but does it rise to the level of, would somebody maybe not do the project because of this risk? Then we don't have to list every little risk that's there. This would really be major risks that we want to disclose that people should know going into this that might dissuade them from approving this project. If they knew about this risk, those are the kinds of risks we want to put in there.

So if you don't have those kinds of major risks, then don't create the section. Yeah, you can skip it. Any approval requirements.

So you're putting in who has approval over certain things. I'm not going to go through the details here because you would have to list your approval requirements. But the whole idea is that certain people will have approval authority over certain things.

And we list out who the project manager is and any sort of reporting requirements. So how often are there going to be reports? Who are they going to be sent to? So the project manager must prepare written reports and submit them electronically to the president slash CEO. And the HR manager must be updated daily, either verbally or in writing.

Hope then is that as we work through this and revise and make changes, that then once we all come to an agreement that the, in this case, president or CEO will sign off on this, sign and date it and say, we are sponsoring this project and we are moving forward with it and the project gets approved. Then we move in to the planning phase.