There are a lot of meeting minutes templates out there (even very fancy ones) that you can use for your projects. But in reality, most of us are juggling multiple tasks at hand and we simply can’t afford to spend too much time looking for templates or trying to write a novel out of a meeting! In this post, I will discuss the basic stuff about meeting minutes, share practical tips on writing them effectively and show you some actual examples from the IT projects I’ve worked on.
The basic: What are meeting minutes?
In most IT projects, we always have meetings usually on a weekly basis to provide status updates and discuss other important topics. Without meeting minutes, we tend to forget what was discussed and action items don’t get followed through in a timely manner.
In simple terms, meeting minutes are official records of meetings that include key decisions made, action items that arise out of it, potential risks and even approval/rejection of a change request. So, it is not about writing down every single word that was said in a meeting!
Why meeting minutes are important in IT projects
Let’s take this typical example that I most often see in projects. In just under 15 minutes after a production deployment, something went wrong and it was already past midnight. The team scrambled to roll back, tried to troubleshoot and analyse the root cause, found it and… no one seemed to remember who made the initial decision and why they used that particular script to update the specific database configuration.
This is where having proper meeting minutes (and also good IT documentation) saves the day. The main benefits of effective minutes are:
Establishes clear accountability
To assign responsibilities, deadlines and owners for each identified action item, and holding participants accountable for their commitments. So, no excuses later!
Provides clarity and transparency
To provide evidence of why and how specific decisions were made, which can help resolve disputes, confusion or misunderstanding later on in the project. No finger-pointing guys!
Helps with assessing efficiency
To review past minutes to check how effective meetings were and find ways to improve future meetings and project timelines, e.g., were your meetings productive or just too long?
Provides historical account
To provide a clear record of past discussions and decisions so that we can use it to track progress and make better choices and/or decisions in future.
The structure and format: Common elements to include
The structure and file format for meeting minutes can vary depending on your organisation, department, project team or client, so there isn’t exactly a one-size-fits-all approach that you can stick to. I’ve seen everything from email threads, Word, Excel and even PowerPoint! In a more traditional setting, some even require the minutes to be printed (poor trees!) and physically signed off. But, all minutes should at least have these common elements:
Date and time of the meeting
This helps you track when the meeting was held and look back into what had been specifically discussed at that time.
List of attendees
Besides establishing accountability, it also serves as proof of participation that they are present and decisions are made by some of them.
Meeting agenda
It provides the participants an overview of what topics are expected to be discussed in the meeting so that they don’t veer off-topic.
Key discussion points
By documenting key points and decisions, minutes prevent information from being overlooked, help resolve topics effectively and provide a solid basis for informed decision-making in the future.
| New to the project? Check your company’s SharePoint (or other similar repository). That’s usually where meeting minutes and other PMO templates are stored. |
What to capture (and what to skip)
Now, remember that you are not a court reporter and not everything said in a meeting must be captured. Even if you have the superpower to document everything verbatim, nobody wants to read a 10-page minutes! Instead, focus on the essentials. Here’s what you should capture (with examples of how to write it better):
Key discussions and decisions made
Key discussions can include technical feasibility, scope change, implementation approach, resource allocation and timeline adjustment. Decisions could range from approving extra budget for the project to prioritising which work items need to be delivered first.
| Instead of this | Write this |
| “Jenny said we should use PostgreSQL but John thought it was better to use MySQL. Later, William mentioned we can use MongoDB. After 20 minutes of discussion, we all finally agree that PostgreSQL is the way to go because of the many benefits it offers.” | “It was decided collectively that the team will use PostgreSQL for user data storage as it is provides better performance and proven to be highly scalable”. |
Action items and deadlines
Action items should include the specific task description, assigned owner, due date, any dependencies and in some cases, level of priority. This is important so that we can follow-up on the matter and see through its closure.
| Instead of this | Write this |
| “The HK country rep raised an urgent change request to display the consent page whenever a user visits the website because the local legal team have implemented a new rule mandating all users to accept the consent before proceeding to use the website. Michael indicated the earliest implementation would be in two weeks due to clashing work priorities but the HK rep wanted it to be done next week. Janice highlighted that she will take this up with the stakeholders tomorrow as the requested timeline is not feasible.” | “Karen (HK country rep) requested an urgent change to display the consent page by Friday 10th October due to a new legal requirement. Janice will discuss with stakeholders on Thursday 2nd October and revert with the outcome by Friday 3rd October.” |
Risks or issues raised
Any potential risks or issues should be clearly identified and documented with owners assigned. If possible, include the mitigations and impact assessments (though these are often tracked separately in a RAID log).
| Instead of this | Write this |
| “Jake, our main contact person representing TPM vendor, is out sick for a week and we cannot reach out to him for further discussion on the storage budget requirements. If we don’t get the budget sorted and approved in time by the steering committee next week, we cannot begin Phase 3 activities.” | “There is a risk that Phase 3 might be delayed if the finalized budget is not submitted to the steering committee by Wednesday 12th November. Wendy to check with TPM’s account manager, Patricia, on Jake’s backup contact.” |
Any dependencies (especially from other team/project)
Dependencies often make or break a project’s timeline. If your project has multiple integrations with other applications that could impact delivery, document it. I’ve seen a fair share of project delays simply because dependencies weren’t captured or addressed in time.
| Instead of this | Write this |
| “The payment gateway team is not ready and they need more time to complete the development work due to recent organisational restructuring that reduced the headcount from nine to four full-time developers. This means that we will have to defer the go-live date for our application because the payment module must be ready before the feature can be enabled.” | “ShipABC’s go-live date postponed as the payment gateway module development cannot be completed by Thursday, October 16th due to resource constraints.” |
So, skip the small talk, random side rants and who’s going where for lunch after the meeting. I can never stress this enough, focus on what was decided, why it was decided (the reasoning matters!), who will do what and when it needs to be done.
Actual examples from different IT projects
Here are three real examples of meeting minutes I’ve written (with sensitive details removed/edited, of course). These show how the structure and format can vary depending on the type of project and the client’s preference.
Example #1 – Meeting minutes of a data centre migration and relocation project
Format: Word file
Points to note: Key discussions and action items were listed separately in two tables. It also showed the “Next meeting” section at the end of the minutes.
Example #2 – Meeting minutes of a storage tech refresh project
Format: Word file
Points to note: Key discussions and action items were combined into the same table. Deadlines and assigned owners were tracked in the columns “By When” and “By Whom”. Since the client required printed copies, a signature section was added at the end of the minutes.
Example #3 – Meeting minutes of a backup, recovery and archival system project
Format: PowerPoint file
Points to note: Key discussions, action items and statuses were listed in a table format. It had an extra page on “Inventory List”. This format was a bit unusual, but it was requested by the client so they could present the minutes to their management board in PowerPoint.
Best practices to follow
Write in simple English and avoid technical jargons
Unless you’re attending a technical meeting, skip the tech-speak. Most minutes are shared with stakeholders who aren’t technical. For example, instead of writing:
“A new table “CTRY_NOTIF_RULES_PREF” will be introduced and when the value is set to “Y”, users will be able to see the communication channels available. This setting is a country-level configuration.”
You could write:
“With this enhancement, countries can decide whether users can view a list of available communication channels in their profile.”
Use consistent templates and formatting
Don’t reinvent the minutes format for every single meeting you attend. Just pick one format and stick with it throughout the project’s lifecycle. Using it consistently means your team members know exactly where to look for the right information quickly as they are familiar with the structure of the content.
Distribute the minutes within 24 hours
While everyone’s memory is still fresh, you have to send it out within 24 hours. Remind participants to review and point out any mistakes – just in case you’ve written something wrongly! Give them no more than five working days to revert, otherwise consider the minutes as final.
Store in a central location (usually the project’s repository)
Don’t let your minutes disappear into inbox black holes. When you send them out, include a link to where they’re stored. It’s usually in your project’s SharePoint or another repository that you use. This way, current and future team members (including stakeholders) can retrace decisions or dig up certain information without bugging you.
Use clear file naming convention
Clear and easily understood file naming convention can quickly give anyone an instant recognition of what type of meeting it was, when it was held and which project it belonged. For example, you can go with <Project Name>_<Meeting Type>_<Date>_<Version> and it’ll look something like this:
CXC Tech Refresh_Weekly Progress Meeting_8Jun2025_v1.0
Final thoughts
Good meeting minutes aren’t just administrative overhead – they’re your project’s insurance policy. When that critical architectural decision needs revisiting three sprints later, or when stakeholders claim they “never agreed to that scope change,” your minutes become the single source of truth that saves the day. They’re your safety net when deadlines slip, bugs multiply and everyone forgets what was agreed last week. Remember, the goal isn’t perfection – it’s clarity and accountability.
What challenges do you face with writing meeting minutes in your IT projects? Share your experiences in the comments below. If you find this post useful, share it with your network!
