Skip to main content

Author: Lauren Zinsmeister

Lauren is a PMO leader with 10 years’ experience at midsize companies. Her specialty is building Project Management practices and teams, including bespoke processes and frameworks for midsize companies.

The Value of a Project Charter

If you’re familiar with the Project Management Book of Knowledge, or PMBOK for short, you know all about the Project Charter and its criticality to the success of a project. The PMBOK says that the project cannot start until the Project Sponsor formally signs off on the Charter.


Having worked at midsize companies for nearly 15 years, I learned that actual Project Charters with formal sign-off are more of a “big company” thing. To date, I haven’t once been required to write a Charter or get one approved to begin a project. Let me tell you why I insist on a Charter and have more than just the Project Sponsor sign off before I kick off a project. Come with me on this thought journey.


If I had to pick a single area of knowledge from the PMBOK as the most critical, I would pick Stakeholder Management. You can have the best plan and the best tools, but a tumultuous stakeholder situation can completely derail a project. On the flip side, you can have a scrappy team with few processes and subpar tools, but with committed people working well together, a project can succeed in spite of other project elements being challenging.


If I had to pick an area of knowledge to be second most critical, it would be Time Management. This encompasses your ability to scope the project, break it down into tasks, understand dependencies, build a project schedule, and keep the team aligned with each other as well as the schedule. In a sense, it’s a superset of a few other areas and captures the core of your project plan.


Enter the Project Charter, which I would argue is the most critical project artifact. Below are the basic elements of a good Project Charter:

  1. Problem statement
  2. Business case
  3. Goal statement
  4. Timeline
  5. Scope
  6. Team members


Diving into these 6 elements, we see 1, 2, 3, and 6 align to Stakeholder Management and 4 and 5 align to Time Management.


[widget id=”custom_html-68″]


Let’s start by looking at the Stakeholder Management elements.

  • Problem statement – Having this clearly written in the Charter ensures that key stakeholders agree a problem exists. They are agreeing on what that problem is. Finally, they are agreeing that this project is the right approach to solving the problem.
  • Business case – Here is where stakeholders are agreeing that this project is worth the resources. It’s possible to have everyone agree that a problem exists and needs to be solved, but it’s something entirely different to agree on its priority and resourcing.
  • Goal statement – Different people can look at the same problem and come to a different conclusion about how to solve it. Articulating the goal in writing will avoid assumptions and make it clear to stakeholders what everyone is working toward. Without stakeholder alignment on the project goal, the project is doomed to become tumultuous when the project team inevitably encounters a fork in the road.
  • Team members – We’ve agreed we have a problem to solve, we’ve agreed it’s worth investing in, and we’ve agreed on what the ultimate goal looks like. This section gets specific about whose time will need to be invested, what the commitment is, and what their responsibilities will be. Key stakeholders reviewing the Charter will be able to think through the impact on their teams and make sure they are able to commit the team members required. They will also be able to identify other team members who may not be listed, helping to complete the project team.


Our remaining two elements are tied to Time Management, though agreement on these is also inextricably tied to Stakeholder Management.

  • Timeline – To be able to write this section of the Charter, you will have had to do some high level project scoping and establish your project structure. Do you have phases? Stagger starts? Is your execution stage planned to be managed using Agile methodology, so the timeline needs to be flexible? All of those considerations and more are required for a timeline estimate. Putting this estimate in front of key stakeholders in the Charter ensures they understand the high level of time commitment. This provides an opportunity for discussion if some stakeholders think it needs to be completed faster or someone says they can’t commit the required resources for the deadline, so the project needs to be extended.
  • Scope – They say the devil is in the details, and this is where those details live. Clarity on scope allows for work estimates, project scheduling, and work coordination among team members. Clarity on out-of-scope work is just as important, because that enables you to define “done,” wrap up the project when in-scope deliverables are complete, and hand off deliverables and/or processes to business-as-usual owners for long-term ownership. The clearer you can be about your scope in the Charter, the fewer struggles you’ll have with scope creep later.


I personally expand on these base elements with a couple of my own tried-and-true tools. Seizing the opportunity to get stakeholder alignment, I also include the below:

  • Communication plan – I use this section to detail what information will be shared with which stakeholders as well as the method I will use. This is especially important if some team members or stakeholders are in different time zones, and even more important if there are people from multiple cultures. Communication norms vary in different cultures, so I like to ensure everyone knows what to expect and has an opportunity to raise a hand if they need something different from what I had originally planned.
  • Project change management – What are the criteria for something to be considered a project change? What process does it go through to be approved? Who has the authority to approve a change? Stakeholder alignment up front will save time and struggle when someone wants to add a deliverable to the project or expand the project to include related work that is discovered during project execution.


The Project Charter provides the best opportunity for you to detail critical components of your project and get stakeholder alignment. You can’t possibly list every detail, but you can align on your plans, processes, and expectations so everyone is working in the same way when questions and challenges inevitably arise.


Eliminate All Meetings? Not So Fast.

Everyone loves to hate meetings. I’ve seen so many opinion pieces on eliminating meetings, all met with cheers from people who are tired of sitting through meetings they don’t find valuable. I think it’s worth a deeper dive into meeting types so we can be deliberate about which meetings to eliminate.


There are three primary categories of meetings:


Problem solving – these are your brainstorming or whiteboarding sessions. I think most people agree that these can’t be replaced with emails and Slack messages. When the creative juices need to be flowing and it needs to be collaborative, it needs to be a meeting.


Decision making – this is a grey area. If the decision involves a complex scenario or significant consequences, I think it needs to be a meeting since it will likely require discussion. In these cases, my personal approach is to send a pre-read to the decision maker and all key stakeholders, which I develop in partnership with the key stakeholders. My template is this:


Background – this explains the broader context of the decision. The decision maker is most likely an executive with many other problems and decisions on their mind, so this helps center them on the situation.


Decision point – explain the exact decision needed. Is it strategic direction where multiple approaches have merit? Is it a vendor choice for software that will have a major impact on daily operations? The more specific, the better.


Options – Write a summary of each option. Work with the stakeholder(s) who prefers this option and include both the benefits and the drawbacks.


Recommendation – Tell the decision maker which option you recommend and why. You know the situation in greater detail than they do, so your recommendation based on detailed consideration is valuable. They may not take your recommendation, but you will have made yourself a resource and thought partner for them.


Having this pre-read ensures everyone is on the same page about what the decision point is and what the options are. This will minimize surprises in the meeting, which in turn will minimize unproductive swirl. This preparation will enable the key stakeholders to argue their point, engage in productive debate, and allow the decision maker to hear and consider options before deciding.


[widget id=”custom_html-68″]


Status – this is the infamous “around the room” where everyone says what they’re working on and everyone else multitasks or dozes off. I believe these are the meetings people are thinking about when they write about how to eliminate meetings. The core of their reasoning is that this information can be shared just as effectively by other means, which is often true. I would break this group into two sub-categories:


Type 1: Small projects with a few primary workstreams. In these cases, I agree status information can be shared just as effectively by other means. The team can collaborate in a project management tool such as Asana or Smartsheet so anyone at any time can pop in and see where things are. Simple automations can remind team members to make their updates, and dashboards can be automatically shared. The technology exists to make asynchronous status updates possible. In an ideal world, everyone makes their updates on time, everyone checks in on status, and meetings only happen when the project requires discussion. In reality though, project teams often don’t take advantage of these options, so we find ourselves in meetings that shouldn’t need to happen.


Type 2: Major projects with many workstreams. In these cases, there are usually clusters of workstreams where people are working together and depend on each other’s work. There are likely also workstreams that seldom interact but will eventually need to interact. In these cases, I’m a believer in live status meetings. Asynchronous updates can work for more regular updates, but I think there’s value in less frequent live status syncs. This gives everyone the opportunity to learn about what’s going on with the more distant workstreams, allows an opportunity for questions and live discussions, and lets people know in advance how something is progressing that might matter to their workstream.


With these meeting categories in mind, how can we avoid unnecessary meetings? Regardless of category, there are some best practices for all meetings. If those can’t be followed for a particular meeting, then that meeting can be cancelled.

  1. Make sure the purpose of the meeting is clear.
  2. Write and share the agenda in advance.
  3. Make sure the right people are in attendance.
  4. Send any relevant information in advance.

If you can’t follow these, for example if your meeting doesn’t have a clear purpose or agenda, then it should be cancelled. To make the most of meetings that do happen, end them with a verbal recap of action items, owners, and timelines, and send a written recap of the same.


The highest potential category to eliminate is the recurring status meeting for small or simple projects. Eliminating these without negative impact to the project will require a team effort. Everyone needs to do their part to update and check in on the project tracker. The leader can set conditions for success by ensuring the project tracker is established and expectations are clear. However, if the team doesn’t hold up their end of the bargain then the leader will have no choice but to schedule recurring status syncs. I’ve found that credibility and trust can be established by following standard meeting best practices, and especially by cancelling meetings when there is no clear purpose or agenda.

With this trust, it’s a little easier to convince the team to contribute by making their updates asynchronously. Little by little, we can move toward that ideal world where we’re only in meetings that truly need to be meetings.


Project Management for Midsize Companies

In many ways, Project Management is more art than science. Those of us who have spent years in the field have most likely studied the science of it through classes and certifications.

There are certainly best practices that apply most of the time and a Project Manager would do well to have that foundation. But dare I say, the majority of textbook concepts don’t apply much of the time? Let me share a story of a project I tried to manage “by the book” that taught me a big lesson about adapting the “book” to the needs of the company and the team.

During one of my early roles as a Project Manager I worked hard to be organized and apply all the concepts I learned while studying for my Project Management Professional (PMP) certification. I remember one project in particular where I meticulously developed a Work Breakdown Structure (WBS) and calculated the critical path. I had a Microsoft Project sheet a mile long, as this was a major project that would take more than a year to complete. All my details were in order. Project Schedule – check.

Confident in my plan, I brought the project team together. I had worked with key stakeholders to identify all the departments involved in the project and worked with those department leads to know which people should represent their department. I shared my project documents with the team and talked through roles and responsibilities. Stakeholder Management – check.

I knew part of my job was to clear roadblocks for the team, which included the roadblocks of me being a bottleneck. I thought the best way to keep everyone informed was to democratize project documents and have teams make their updates directly rather than funnel all updates through me. I created automations to remind team representatives to make weekly updates.

I had automations to notify people when one of their predecessor items was updated so they would know right away. I had automations to notify both me and team representatives when an update was overdue. Everyone had access to view, so no one ever had to wait on me to share a document or give a status update. We had weekly status meetings to allow for discussion and broader visibility, as well as ad hoc meetings for specific topics as they arose. Transparency and Collaboration – check.


[widget id=”custom_html-68″]


If you haven’t already guessed, let me tell you how this worked out. Not a single person ever went into the project tracker to make an update. Not a single person ever went into the project tracker to see status. My first pivot was to start collecting updates weekly and input them into the tracker myself. This allowed me to stay closer to the project details and gave me an opportunity to do a weekly assessment of project health with more context.

Those weekly conversations turned out to be so much more valuable than independent updates in the tracker. Every week, I would take this updated tracker and the deeper context I had to give a status update. I would share my screen and show the tracker so everyone could see visually where we were compared to the overall plan.

If you haven’t already guessed, let me tell you why this failed fast. If every team was meeting with me weekly to give me an update, why did they need to sit through a weekly status meeting of me telling them where their items were in the project? They didn’t. I lost the team’s engagement fast. My next pivot was a change that has stuck with me through the years. I did the legwork to meet with teams, understand their status, challenges, dependencies, needs, and projections. I consolidated all the information and culled it to down to what was critical.

Every Monday I sent an email with the week’s game plan, including all work expected to be done with deadlines and names of people responsible for doing the work. Every Friday I sent an email as a Reply All giving an update on what had been completed as expected, what had changed, what was delayed and why. If something meaningful changed and needed discussion or a decision, I would schedule a meeting to discuss it. We now had emails for things that could be emails, and meetings for things that needed to be discussed live.

This raised my credibility with the team when I called a meeting, because they trusted that there was something meeting-worthy to discuss rather than just a status update that could and should be an email instead. My Monday “game plan” emails served as an easy reference for project team members to know exactly what they needed to work on, which increased the rate of project work completion because there was more clarity and it was easily accessible.

Nearly 10 years later, I still rely on this approach. My Monday and Friday templates have evolved as my projects have changed, but this approach has proven successful time and again.

This semi-informal approach to Project Management would likely not succeed at a company with tens of thousands of employees. With larger teams and greater numbers of stakeholders, proper project management tools and formal project communication methods are likely necessary. On the other end of the spectrum, this semi-formal Project Management with meticulous planning and centralized tracking is probably more than is needed at a small company.

When teams are small and work closely together, it’s much easier for everyone to know what everyone is working on without a person dedicated to keeping it all organized. My time at midsize companies has helped me find this Goldilocks approach somewhere in the middle.