In my previous post, I described how we can visualize our project tasks. We can use project plans or project roadmaps according to our company structure, but before we start a project we need an explanation document.
There are several methods for presenting project ideas in kick-off meetings, but I don’t think you have to waste your time creating project presentations, tables, reports, and more. A project charter is what you need for a fresh start.
A project charter is a one-page document that describes your motivation for the project. The charter page is a starting point for every project idea becoming a new request and indicates your objectives, project risks, advantages, and key stakeholders.
We use Excel sheets in every project to follow multi-team requirements. The charter (the first page) is used for explaining the project at a high level to the business side of stakeholders, C-suite, managers, or kick-off meeting members.
Unlike project roadmap or plans, we don’t need to add every detail inside this table. We should avoid over-explanations. Exceeding one page will decrease the charter’s value. This is a quick win page, we should always consider the overall picture while adding a new line.
Without any other explanation, people should be able to look at a project charter and understand the project in minutes. Hokey-pokey! It’s that easy.
For the implementation part, I recommend you create a new page for “phasing” the project. Before everything starts, you can show the important processes and iterations. This will help everyone see where the project is going with a wider picture.
Project charters aim to answer why we need this project and what we will accomplish at the end of the deadline. It is also used for handshaking with the business team about the project scope, sources, and deadlines at a high level.
We can separate its usage before and after idea acceptance. Before acceptance is, as I described earlier, used for explaining the what and why we should start this project. A summary of pros, cons, risks, and advantages helps us to show our purpose.
After acceptance, the charter shows common goals and objectives we should lead during the project timeline. Required resources and key members will be decided and promised with a specific deadline. As a result, we can say that it’s a contract each stakeholder should follow.
A project charter is created by the idea owner, but the entire business team creates the chart with business impacts and revenue points. The document is basically the idea owner’s first statement about the project. After alignment and kick-off, the project charter is still important for the idea owner to show key members and related people lists.
As a product manager, once I have a new idea, I also create a project charter and write the problem with examples, my motivation for solving the problem, and its advantages. There are no boundaries for project charters, everyone can create one to explain their idea.
A one-page table is enough for the project charter as I described earlier. You can use simple templates with the required elements as below:
| Element | Description |
| Heading | The name of the project |
| Project type | This field should be selected from the product vision template. You should have a purpose for your projects and differentiate the projects according to your annual product vision. For example, cost reduction is a product vision and the projects can be selected from project pools according to their types. Your project idea can solve a problem, process, or implement a completely new logic. This field is important in that aspect, everyone can understand the concept directly |
| Objective | The initiative of the project and the constraints can be explained in this field |
| Deadline | Time or quarter information. This will be the business delivery date expectations. Deadlines can show the entire project’s delivery date or a specific MVP scope. Of course, deadlines can change along the way, but we should be aware that we are giving promises to the business team once we start the project |
| Impact (EBITDA) | Budget, revenue, and business impact can be used according to the company’s vision. You can also use the same legend from the project roadmap (S, M, L) template.
For example, less than $100k = S, $100k– $500k = M |
| Size/complexity/risk | This field will be the project’s complexity and risk statement. You can use the same legend from the roadmap (S, M, L) template.
For example, One team resource needs one month of effort = S, multiple teams with one month of effort = M |
| Success criteria KPIs | Our goals to achieve the objective will be explained with numbers. This field will show us when to stop or decide if the project is successful. Be careful when you are selecting your success criteria because they all should be measurable KPIs. I suggest comparing it with earlier numbers. If people know the effect your idea will have on the product’s/company’s success, they will have more motivation to support your project:
Increasing X process performances by % Decreasing customer cancels by % for Y process |
| Scope | A high level of the requirements can be listed here. The components we should adjust can be listed as a rough list. We can add scope bullets in a phasing document with iteration details. We don’t have to deliver all scope in one iteration. Product managers can create MVP or prototype scopes with the scope’s high-level requirements. |
| Advantages | After this project, what will we gain? The results of the scope will be listed. You can add a pros/cons section to discuss in more detail. I believe listing advantages are more important than showing revenue. We have a statement, an idea, or a problem and we have to polish the project’s reason as much as we can |
| Execution risk | This is where to explain the concepts we should be aware of before the project’s execution. We can see the bottlenecks and go-live problems in this field. The IT owner can lead this part with the project owner.
For example, customer-facing risks, legal risks (GDPR), scalability risks, etc. |
| Roles | You should list the roles and teams with responsible team members to show your project team. It is vital to know responsible members as soon as possible so you can discuss details before kick-off.
|
I created a charter template (shown below) for free download and use! These are all sections and details that I find helpful to include in project charters. It doesn’t have to be anything fancy, but this is a great way to stay organized:
You can download the charter template from this link.
Once you create your idea documentation as a charter, you can clearly see that delivering everything in one phase is almost impossible. What you will do is simple, add your scope as a summary inside the charter and prepare one priority list. Certain phasing and MVP scopes are created by product managers but you can indicate your point of view for the project’s roadmap.
The phasing page is a short version of the roadmap. The idea owner can show the vision clearly and in detail. The elements are listed below:
I added the below phasing table inside the example template:
MVP (prototype) and additional two phases can be summarized, but trying to define the third and fourth phases are unnecessary. After the first or second phase, you will see the project’s actual results and things can be changed along the way so the project itself.
Once you finalized the charter and phasing on a high level, the time has come to present your idea to key members. Charter and phasing sheets are good materials for everyone to understand the idea, but they’re not enough to illuminate all questions.
This creates a bottleneck here: should we increase the explanations and decrease the readability, or should we keep readers in the dark? While presenting my ideas, I try to create an additional sheet for pros, cons, and options. These sheets help show the other options I have already thought of but eliminated for some reason. You will get a lot of questions about your conclusion, so you should prepare yourself with everything you have already considered.
For example, if you get the “why we should invest in your idea” type of question, a summary table as shown below can save you.
Start with the options you can give with a description and details (if required). Continue discussing your options with pros and cons. This kind of flow will help them understand the path you’re coming from and arrive at the same point as you.
If you’ve also added data to your table, I can’t think of a better defense than this:
Let’s say you have additional options but challenges are more dominant. You can just list them in a table like the one below to show everyone that you’ve considered that many possibilities and evaluated all the risks before you came to this meeting:
In my earlier companies, there were strict rules about presenting your ideas. A project word documentation with requirements meant tens of pages to write. After the word document, you should prepare a PowerPoint (with a company-specific template) to summarize the word document.
Believe me, I sometimes did not present my ideas because of the documentation burden. We live in a time when people say if you can’t finish your product in three months, you shouldn’t even start it at all. As a leader/manager, our job is to allow our team to create as much as they can. Not to create new headaches.
Some love to use idea boards like Miro, Ideaboardz, Creately, Lucidchart, etc. I completely suggest you use Miro for your brainstorming or event-storming activities. Also, Lucidchart is my favorite to create flows and show the processes to support my project idea.
There are dozens of easy-to-use free tools to make your team feel creative. Do not add unnecessary burdens to them, they already have their daily work.
You can create a project charter and phasing with project management tools, but I found that Excel is super useful for tracking projects. I only can recommend you use the tool you feel more comfortable with.
Fancy presentations or documents can be time-consuming for agile companies, so focus on your ideas and trust the data you collect — not a shiny template. Be more data-oriented and show your idea’s impact to stakeholders!
Find me for creating a starting document, I will be more than happy to help you 🙂
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Build a product management AI agent in 2027. Start with feedback triage, compare no-code tools with the Responses API, and test whether it saves time.
Move AI pilots toward production with PM playbook for ownership, funding, and readiness. Learn when to scale, revise, or stop your AI pilot.
Learn how to spot cognitive debt in AI products, preserve critical user skills, and measure outcomes beyond speed with helpful tips for PMs.
Learn how to turn regulatory requirements into clear product requirements, define acceptance criteria, and keep your compliance work current.
Learn more →
