How to Get the Most Out of Your Project Management Software

Your organization spends thousands of dollars on project management software each month. The creators of your solution put heart and soul into it. But still, you use only 50% of its capabilities at best.

That’s what I noticed again and again in all organizations I worked for.

Below you’ll find practical tips on how to tap into the power you already pay for. It will boost the value of your project management software and the team’s efficiency at least twofold.

#1: Keep these 3 project documents inside your toolbox

Most project managers use their robust project management software as a simple task tracker. And a Gantt Chart to move the bars around.

OK, I get it.

The popularization of Agile Frameworks and Productivity systems like Getting Things Done (GTD) are on the rise. Teams try to simplify processes. So, they don’t use tools and documents from traditional project management.

Even if a team tries to keep everything in one place, many things still happen in emails or Zoom calls. And information gets lost in those communication mediums.

Here’s what I discovered in practice:

It doesn’t matter what project management methodology you use or what industry you work in. You need to have these three documents:

1. Project Charter
2. Requirements Traceability Matrix
3. Risk Register

Let’s review them one by one.

Create and keep a project charter in sight

All project management apps share the same problem. When you log in, it all starts with planning. It prompts you to add tasks and estimates, assign people, and build a Gantt Chart.

That’s wrong! You should always start with “project initiation.”

Let me explain it…

The main goal of any business is to make money — reduce internal costs and maximize the profit margin. Project profitability is non-negotiable, even if the organization wants to spend all it earns on a good cause. Therefore, an organization allocates some resources and people to achieve a specific objective to increase revenue. For example:

• Create a product or service
• Become compliant with new regulations
• Improve business processes, etc.

If you spend the allocated resources efficiently, you get a higher Return on Investment (ROI) and other benefits.

Organizations use “Projects” as a tool to move towards objectives in a controlled way. That’s why experienced Project Managers always create a Project Charter – to make these objectives crystal clear for all stakeholders and the team. After that, they restlessly work only towards that goal.

What’s a project charter?

Project Charter is a simple document you create at the start of a project. It includes high-level information about the project:

• Objective
• Business Case
• High-level requirements
• Assumptions
• Constraints
• Risks

Here’s the secret people don’t understand:

You don’t need to create a formal document and get all the sign-offs to reap the benefits of a Project Charter. You can collect the same information and keep it in one of the tasks.

Moreover, a charter should not describe everything in excruciating detail. It’s not a contract. Your goal is to outline the boundaries of the project.

Then, when you are in doubt with decisions like:

• Do we need to do this task at all?
• What solution to choose?
• Should we accept this change?

Your first action should be to check it against the Project Charter. Does it help you reach the project objective? Is it aligned with the business case? If not, then it’s not a part of your current project.

If you notice that you get too many changes or doubt the project’s feasibility, it’s a sign that you need to adjust the Project Charter. You need to initiate a discussion with clients and sponsors. Together you’ll ensure that the project objective is still valid.

Sometimes you’ll need to cancel the project and start a new one.

So the main trick here is:

Keep the Project Charter at a visible spot in your software all the time. Revisit it regularly!

Project charter in Paymo

Requirements Traceability Matrix helps to keep things integrated

Requirements Traceability Matrix (RTM) is a simple spreadsheet. But it’s a powerful integration tool. And you need to create it before listing out any tasks as well.

Requirements Traceability Matrix helps you to connect and align requirements with different aspects of a project.

The key columns that you have in RTM are:

• Requirement Title
• Requirement Short Description
• Requirement Requestor
• Business Need
• Project Objective
• WBS Element
• Specification
• Test Cases

Requirements Traceability Matrix

Stick with me here because it’s important.

You are primarily interested in the connection between the Requirements and the Project Objective. It will ensure that you do only the work required for this project and its objective.

You may also analyze the relationship between a requirement and its requestor. This way, you can ensure that you collected requirements from all key stakeholders. Also, it can help you prioritize the requirements.

You can connect requirements with specifications and UI designs for convenience as well.

The connection between a requirement and test cases will show you the test coverage. But that’s not all…

You can make a connection between requirements and WBS elements as well.

1. It shows you when the team will deliver the requirements.
2. Stakeholders will know when to expect things they requested.
3. It helps you avoid scope creep.

Again, this tool is scalable. You don’t need to fill in all the columns. Use only what you need to ensure you work towards the project’s objective.

Create a transparent Risk register

Do you manage risks transparently or hide them in your estimates as buffers?

Risk register

Let me elaborate on risk management.

You have a requirement, milestone, or deliverable. They have some uncertain events or conditions that may or may not happen. But if it happens, it will negatively impact your project.

In an ideal world, you list all the risks and analyze their probability and impact. And you decide what to do with the most severe threats.

You can add an extra day to a task to “soak up” any impact. You’ll work it out on the fly. But that’s not the best approach to handle risk. Here’s why:

1. Due to Parkinson’s Law, you’ll always eat up the buffer you added.
2. You don’t know whether the identified risk happened or something else went wrong (e.g., low performance).
3. You don’t know the overall risk level of your project.
4. Many risks slip through the cracks because you don’t have a process to identify risks.

The better way to manage risks is to have a Risk Register right inside your project management software. First, you can link risks to specific tasks or milestones. Second, you can create mitigation plans and reserves as additional tasks. They become a part of your project plan.

Account for the risk reserve

The main idea is to proactively and transparently work towards mitigating or avoiding risk.

And here’s the secret:

You use allocated time and resources only for the risk you identified. If the risk doesn’t happen, you release the reserves. And everyone’s happy because you are ahead of schedule. Your plan got some flexibility.

But don’t adjust the project deadline yet! I can promise you that other unexpected threats will happen, and they’ll eat up some of this flexibility.

Now, risk management is transparent and integrated. Your clients and team know when to expect risk and what to do if it happens. You have full control over the reserves you allocate.

Review your integrated Risk Register regularly with clients; you’ll get their support if something goes wrong.

Now let’s boost the structure of your projects and make them manageable.

#2: Create a proper Work Breakdown Structure

What do you see when you get into the main area of a PM application? It’s the task list, isn’t it?

Task list in Paymo

Wrong! It’s a Work Breakdown Structure (if you are a project manager, you guessed it correctly 😉 )

WBS definition is confusing. So, I’ll put it simply:

A Work Breakdown Structure is a tool that helps you break down the project into tangible pieces and identify 100% of the work that needs to be done by the team. Also, it makes the project manageable.

Work breakdown structure

The great thing about WBS? You don’t need some special built-in capabilities. It’s more of an approach to how you organize project work.

And here’s why it’s important.

How does Scope Creep appear?

Imagine we have a Web Designer. You give him a “project” to create a full set of designs for a client.

He goes all-in and creates tasks at once:

• Select brand colors
• Select fonts
• Create wireframes
• Search for images
• Prepare the client’s package

(Notice verbs in tasks’ naming. That’s a pitfall. I’ll explain below.)

In a few days, he comes and says, “I have finished the project. What’s next for me?”

“Did you get approval from Jane already?” You ask.

“Ehhh…no.” Says the designer. “I’ll send it for review now.”

That’s how scope creep appears.

Your Web Designer sends the package for review. Then, he needs to wait for approval, hopefully doing some other work. But approval doesn’t come easy. Jane asks to make some changes because “we can’t use these colors” and “are these images licensed?”

The Web Designer will spend a few days more. If no other corrections follow, we’ll finish the project.

It may seem like an exaggerated example, but it always happens this way.

People think in terms of their own work. They don’t consider all the efforts it takes to get validation from clients on the final product or result. Or they don’t have a full picture of the project scope and assume someone else has a task to do the work later.

How to make a project manageable

A product that is 98% done has zero value. Only the product we can hand off to the client or release to the market has business value.

It’s the main principle of a Work Breakdown Structure:

We decompose the project into tangible pieces that clients can see and play with. These are fully finished pieces of the project.

There are two main WBS Elements: Deliverables and Work Packages.

A deliverable is a tangible part of the work completed to meet project objectives. It can be a part of the product or service that stakeholders can try or see. It can be a project document or a part of the Project Management Plan. In any case, it is something important we need to create to finish our project successfully.

A work package is simply a tangible and finished piece of a deliverable.

List of deliverables in Paymo

So, what’s the main takeaway?

First, break down your project into fully finished pieces. Then, list out actions you need to perform to get these pieces of work to your client as a product.

Subtasks in Paymo

Five main principles of a high-quality WBS

There are books on how to create a correct work breakdown structure. You don’t need to dive too deep into it unless you are a senior project manager.

That’s why I outlined five simple rules to create a powerful WBS.

Use nouns and adjectives—not verbs—for Deliverables

It’s a simple change in the mindset and naming of your work. But it’s critical. When you use a noun, you describe a tangible piece of finished work rather than a process.

So, don’t name it “Create UI Package.” Make it “Approved UI Package.”

I’m sure you agree that the second variant encompasses much more work from the title.

Another example.

In software development, we often use the “Bugfixing” activity. But it’s a process. It’s hard to describe what we get in the end.

Therefore, it’s better to name the deliverable “Gold Master” or “Release Candidate.” Then, you can give it a proper definition of quality. It will identify what defects you must fix before you can call it a GM or RC.

Quality WBS defines 100% of Project Scope

When you decompose a project into tangible pieces, don’t forget that you need to put those pieces together into a product or service. That’s why you need a separate deliverable to integrate it all.

But likewise, you should be 100% transparent about the work you need to do.

Lots of companies hide complexity and management tasks. The project team seems to do some magic and produce results—we’ll also discuss it below. For now, you need to be fully honest about all the effort it takes to create a work package.

Here’s another typical example of scope creep.

We all know that meetings happen, and they take up 1-2 hours per day for a team member. That’s your daily meetings. If you know you need a dedicated meeting to implement a work package (e.g., knowledge transfer, a demo, etc.), make it a separate task of that work package.

Quality WBS includes project management deliverables

It takes 2 hours for a project manager to create a Gantt Chart in a project management software—plus 47 person-hours of meetings with the team.

It’s a common misconception that a project manager does project management alone. In fact, there’s nothing a PM can do alone. He needs input from the team all the time.

I get it. Clients may not like it. But that’s a reality.

It’s easy to explain the cost of project management benefits. It’s much harder to come up with excuses on why you always get behind the schedule.

WBS 100% rule

WBS Child levels contain 100% of a parent level

It doesn’t matter what level you work at. The following rules should apply:

1. A sum of child tasks should contain 100% of work of a parent Work Package.
2. A sum of child Work Packages should include 100% of a parent Deliverable.
3. A sum of Deliverables should result in the final product or service—and acceptance from clients.

By the way, the same applies not only to work. Costs, efforts, and duration should also sum up to the parent level.

This way, you can apply the most accurate estimation technique — the Bottom-Up Estimation.

A Project Team Always Focuses on Fully Finishing a Work Package

If you do it correctly, your team will consistently deliver tangible and finished pieces of a project. When clients want to see the progress, you don’t send them a report with abstract numbers and charts. You give them something to test and play with.

Let me explain it…

You can schedule tasks from different work packages and deliverables in one sequence. Sometimes you’ll win a few hours or days due to optimized resource allocation. Some project management apps can do it automatically. However, you’ll introduce lots of communication overhead and context switching.

In practice, I noticed that focusing on one (or two) deliverables at a time yields the best performance. Schedule and focus on work packages from one deliverable. Then, sequence work on the following deliverable.

Ideally, allow some free time between deliverables to get acceptance from clients and fix defects.

And this leads us to the next critical point.

#3: Encourage task-based communication

Let’s analyze a life cycle of a task (or a piece of project work):

1. A Business Analyst (BA) discusses the requirement with clients at a meeting.
2. BA writes down requirements in a Google Doc.
3. The project manager creates a deliverable in project management software.
4. The team discusses requirements on a Zoom Call.
5. Hopefully, someone sends an email with meeting notes.
6. Separate team members clarify requirements related to their part of work with BA in Slack.
7. One-on-one discussions happen on a coffee break.

This approach to communication isn’t efficient. There are so many tools involved. Moreover, it produces silos.

Keep everyone informed about the discussion history

If one person has a question, ten other team members also have it. They are just shy to ask it. Or they don’t need this information right now.

That’s why you need to keep everything in one place. As much as possible, you need to use the capabilities of the tool to collaborate and communicate. Moreover, you need to circulate all the information within the team.

For example, you can create requirements inside the project management software. In practice, you don’t need much. You need a rich text editor and the ability to attach files and include in-text images. So, don’t use Google Docs or MS Office. This way, you’ll keep all related questions and comments in one document.

You can keep meeting notes in comments or a separate task dedicated to the task (or Work Package). Capture action points right away – don’t send an email.

I’m a strong advocate for replacing emails and instant messengers (Slack, Skype, etc.) in favor of a chat below a specific task.

As a communication method, comments and task-related chats are better than email for one reason. It’s a lousy place for internal politics and unconstructive debates. Moreover, a conversation always has a context.

That’s where it gets even better—if you follow my advice on WBS.

Work Breakdown Structure is not only a visual representation of the project work. It’s a powerful tool for communications, tracking, and integration.

For example:

1. You can use the deliverables level to track costs and set milestones.
2. Deliverables are excellent for scope validation and getting acceptance.
3. Work Package level is great for monitoring risks and for reporting.
4. You can control the project scope and resolve daily problems on the activities level.

WBS is a framework for communication. Whenever you need to discuss something with clients, you can point out a deliverable or a work package to provide context.

But it’s not enough to keep the whole team there if you want to get the most out of your project management software. You need your clients and other stakeholders to collaborate with the team.

#4: Invite stakeholders to participate in the team’s work

There are many pros and cons of getting all key stakeholders into the daily life of a project.

Like it or not, clients and sponsors are part of the project team. Likewise, you can treat some key stakeholders as part-time team members.

They have certain responsibilities that usually fall under one of the two categories:

1. Provide requirements (including non-functional requirements).
2. Provide approvals and sign-offs (formal and informal).

You need to plan and account for the availability of these stakeholders. Moreover, you must always keep people engaged with your project. Otherwise, they’ll be less motivated to help you manage your project.

Don’t be afraid of full transparency

Some managers think clients start to micromanage and distract the team. Others don’t want to show all the chaos (read: magic) of a project’s daily execution.

But think about a Web camera in a kindergarten. It’s an excellent tool for parents to monitor their children and teachers.

From one side, parents can check how their kids are, and teachers work. On the other side, it disciplines teachers to do their best work all the time – everything is recorded.

• But do all parents watch the stream of that camera all the time? No.
• Do they rewatch recordings without a strong need? No.
• Does it give any additional control to parents? No.

It merely gives access to an instant progress report. It removes the client’s anxiety about the team’s commitments, performance, and availability.

It’s a common misbelief that clients should suffice with a weekly progress report. Business owners care about their products as much as they care about their own kids. They need a feeling of control. Usually, the feeling that YOU keep the project under control is enough.

So, provide access to all project information to key stakeholders. In a few weeks, the collaboration will normalize, and they will take ownership of the project.

But that’s just a starting point.

Build cadence with the team

Let me ask you this:

• Do you want your stakeholders to be helpful and available?
• Do you want to get support from clients in challenging moments?
• Do you want all of them to follow your plan?

Then, all you need to do is to delegate responsibilities correctly.

Don’t assume clients and other stakeholders know their roles and responsibilities on the project. If you don’t communicate your expectation, they will take a role they are comfortable with:

• Clients will demand.
• Authoritative stakeholders will control.
• Your boss will disappear until the next disaster.

For example, I have a Product Owner. She has the authority to provide business needs and expects us to generate solutions. On the other hand, she’s responsible for clarifying requirements with our team. So, she needs to dedicate time to it. And she must provide a formal sign-off on requirements in the project management software.

It seems evident that a Product Owner should know these responsibilities. But in practice, it’s not true. We had to communicate a lot to get to this point. We had to spell out what we expect from a PO. Likewise, we had to agree on things we did NOT need from her to make our work efficient.

You need to set clear expectations for each critical stakeholder on your project. In some cases, you need to do it multiple times. In the end, they become a cohesive part of your project team.

#5: Create templates and workflows for recurring entities

Create a template if you do something in project management more than twice. For recurring tasks, you need a workflow.

Nothing fancy. A copy-and-paste structure of a defect report or a simple diagram will do the work.

The idea is simple:

Team members should not spend mental bandwidth on inventing a format or structure from scratch.

I understand that it’s all specific to your project management approach. So, the examples below are just to boost your creativity.

Here’s how it works…

For example, you can create a whole project template as a starting point. At least Include tasks related to initial project management activities and the hand-off process. And if you do typical projects, add major deliverables and milestone placeholders.

It will ensure you won’t forget the essential activities of the project initiation. Moreover, you’ll have some structure to begin with.

Some project management software allows you to create template projects and tasks. Check if you can avoid repeating activities and save even more time by using built-in templates.

Project template in Paymo

But you can also start with “simple” templates…

Create one task or a document and outline the main sections. Do all the formatting you need in the final document. And explicitly state the format of the data.

You can add notes explaining what information to include and in what format each section. Then, copy and paste the template into a task and fill in the blanks.

Let me give you an example.

Simple 5-minute progress reports template

So, as you can see, the daunting experience of creating a weekly project status report transforms into copy-pasting information from the queries you made in advance.

Here’s where it becomes even better.

You can delegate collecting the information to other team members. This way, you only need to write the summary to focus the client’s attention on the most critical topics.

In most cases, stakeholders don’t need an in-depth and detailed report. What they need is the feeling of control. Usually, if you state, “The project is on track with no impediments,” that’s the only thing they read from the report.

Tips for long-term product development

Nowadays, we rarely do a solo project. Most of the time, it’s an ongoing iterative product or service development. It can last for many years.

Therefore, in your project management software, you’ll see projects that merge one into another.

That’s why the critical point here is to set the boundaries for the project per release or some development phase. You need to create a Project Charter for each release and identify the goal and constraints.

Then, using a project objective and a “release version” or “phase gate,” you filter, group, and prioritize requirements in the Requirements Traceability Matrix.

You must create a Work Breakdown Structure based on the collected requirements to identify the project scope. Again, you link requirements with deliverables in the RTM.

After that, you identify deliverables or work packages risks and link those items with risk entries in your Risk Register.

Daily you, your team, and stakeholders work on specific tasks to produce work packages and overcome related risks. It happens in one tool and within the context of a particular assignment.

The idea is to keep it all in one tool linked with one another as a cohesive whole. Only this way can you prove that you efficiently used the allocated resource. Moreover, you didn’t use these resources on tasks or risks from another project or in vain.

Five vital areas a great project manager needs to master ASAP

What I covered above are the practical steps to project integration. We integrated project goals with requirements, scope, budget, schedule, and risks. We also integrated the objectives and scope of work with key stakeholders.

But that’s not enough said.

As a project manager, integration is the main reason we have a job. But you need to cover four more critical areas to be a successful PM. So, if you want to learn more about the other four areas, you can click below to access my resource guide.

I’ll not merely outline the areas, you’ll also get access to all the required knowledge and skills in the guide—get access here.

First published on December 17, 2020.