Kentico partner Konabos' Senior Delivery Manager, Marcin Sadowski, wrote a helpful guide that covers key practices leading to success for a project.

I think these thoughts are valuable for project managers and anyone on a delivery team or in a stakeholder team's leadership.

Project charter

Marcin starts out describing the role and value of a very important foundation for successful projects - a project charter. This document outlines the most important information that needs to be identified and recorded at the beginning of a project.

This document serves as the foundational reference for the entire project, outlining key aspects such as the project’s purpose, goals, and high-level scope. It should also detail the project’s timeline, including major milestones, deadlines, and key deliverables. The charter defines the communication plan, specifying the channels, frequency, and formats for project updates [...]

I love this list because it makes the most important knowledge explicit.

No more assumptions

It's very easy for project teams (whether at an agency or as part of the stakeholder business) to have a different assumption about the state of the world than the stakeholders. You might think, "How is this possible? Everyone involved in a project is constantly talking about these things. Of course, everyone is aware of goals, scope, and purpose before a project starts!"

Even if that was true (it isn't in my experience), people's roles and employment within organizations change over time.

What if you are on the stakeholder's marketing team or an agency account manager asked to help with project workload and you start in this role the day after a big project kicks off? You weren't around for all those early discussions and planning so you will either spend a lot of time asking around for the information you don't have or you will make assumptions about the project that are hopefully correct.

Even if there are no key people joining a project part-way through, it's always worth replacing assumptions with knowledge using a document like a project charter so all parties involved have something to agree to and reference in the future when they're heads down trying to achieve their original goals.

Make it explicit!

Risk identification

Later it's mentioned that a project charter is more than just its aspirational items like a project's goals and purpose.

Other critical elements include the project budget, risk assessments, and approval criteria (+DoD) [...]

I've found that identifying risks from the outset is extremely helpful in bringing misaligned assumptions to light. A development team might view the complex CRM integration as the biggest risk because the CRM team is doing a large migration in the middle of the project timeline.

The stakeholder CMO might know the CRM migration is actually very small in scope with no downtime for integrated systems and view the deadline as the biggest risk. Why? Because the organization's large annual conference will begin shortly after the project launch date and the event will rely on some of the project's capabilities.

Both of these are real risks for each group, but they might not known by others or maybe they're seen as less of concern - e.g. "We can easily make the deadline if we can trim the scope of the complex CRM integration." or "We can reduce the risk of the CRM integration by helping you coordinate with the internal CRM team."

Project planning

Marcin then covers two interesting topics in project management - tools and terms.

Tools

I imagine every team has their own preferences when it comes to which tools they use and how they use them.

Using tools the wrong way or using the wrong tools altogether can really hurt a team's momentum. This can be due to the number of clicks a tool requires to perform a simple operation or how accessible information is in the tool. If it's hard to find information, people will stop looking for it, which could be disastrous if the hard-to-find information is the project charter!

When managing a set of projects for a single client, the typical approach is to create a separate project within Jira or Azure DevOps for each new initiative. However, in my experience, a more efficient and scalable solution is to create a single project in Jira or Azure DevOps dedicated to the client

Here, Marcin identifies a practical example of a way to optimize the use of a project management tool. It's good to learn from past projects - what works and what doesn't - and also learn from other teams. Let their experience be your knowledge.

I think it's important for team members to accept that no tool is going to be perfect and instead of trying to reach "perfect for everyone" ask themselves "What are the things we've struggled with the most on past projects and do our current tools cause those challenges or help us resolve them?"

Terms

Agreement on big picture topics like project scope and goals are important among all people participating in a project. It's also important to agree on terminology for day-to-day tasks, which Marcin covers by defining the terms used for work items.

From my personal experience:

EPIC: Work that spans more than a month.

FEATURE: Work that takes more than 3 days but less than 3 weeks (at least 2 features make up an EPIC).

USER STORY: Work that takes more than 2 hours but less (or equal) than 3 days (at least 2 user stories make up a FEATURE).

TASK: Work that takes less than 2 hours (to make it clearer I limit typically up to 6 within a USER STORY).

Later, he also defines the difference between sprints and iterations.

It's fine if teams have different definitions than Marcin's for these terms. If they are too different from industry norms you might have challenges communicating with new team members or stakeholders, but there's room to use what works for you.

But, you absolutely cannot have multiple definitions for these terms on a project!

A team needs to agree on the terms and communicate them clearly and consistently to stakeholders.

Communication is key

You might already see a theme here. Each one of these tips is related to how we communicate with each other when working collaboratively.

It's also not just the implementing teams that are collaborating and communicating - successful projects feature stakeholders that collaborate with the teams implementing the solution.

Is there such a thing as over-communication? Yes! However I think it's more common to under-communicate or communicate the wrong information - something that isn't important or needs clarity (not necessarily more details!)

Wrap up

Be sure to read Marcin's full post Key Practices for Successful Project Management over on Konabos' blog.

Let me know in the comments some well know or surprising project management practices that have been successful for your teams. I'm also interested in learning any project management conventional wisdom that definitely hasn't worked for you in the past.