Voices on Project Management

by Christian Bisson, PMP

Documentation—at least on IT projects—is one of those great project challenges. Documenting everything (and then keeping it updated) can be tedious, and requires a lot of time and discipline. But documenting nothing can leave people lost as a project evolves.

Like many things in life, balance is everything. Documentation doesn’t need to be a pain. It just needs to be relevant, easy to find and reliable.

Relevant

Documents can easily (and quickly) become obsolete, therefore it’s important to limit documentation to the information that can help the team save time and avoid errors. Stick to the most important elements, such as project scope, important links, FAQs, key decisions, approvals, etc.

Easy to Find

If information is scattered between emails, a server, a computer and a filing cabinet, chances are team members will skip looking for it and simply ask around (most likely starting with the project manager) to find what they’re looking for.

There are several software options out there today that are great for storing and organizing documentation, like Google Drive or Confluence (part of the Atlassian suite). Each allows you to consolidate documentation in one spot and provides access to simultaneous editing and commentating features.

Reliable

If you follow the first two tips, you should only have to maintain a limited amount of information in one easy-to-find location. This is essential because documentation that is not updated can have negative consequences on your project. It can mislead team members and accidentally force them into working off of outdated information.

Where do you store your important project documents? How do you ensure they are relevant and reliable? Share below!

by Taralyn Frasqueri-Molina

In a small business, like a startup, organizational project management (OPM) may seem too big. At a large blue chip, layers of OPM may be standard operating procedure. But what if your org is somewhere in between? On one hand, you're past the days of moving furniture yourself, on the other hand, you're not yet cutting paychecks for 2000+ employees.

First, let's establish that OPM is a good thing. Linking strategy with implementation across an organization to deliver on portfolio promises and realize value is, trust me on this one, a good thing. But OPM at scale is even better. And that is because if you don't scale OPM to where your org is right now, it may seem that OPM is too complex to even attempt at all.

And if OPM is a good thing, then no OPM is probably not so good.

I've seen what happens to a business that doesn't have an OPM strategy in place. The business is moving along successfully but then the stumbling starts, and then maybe stops, but then it starts up again and continues unabated. Teams are frustrated that progress has halted and find they're taking the blame or blaming each other. Leadership pushes the same answers to newly arisen problems—work harder, faster, longer.

The Benefits of Scaling

OPM at scale ensures the strategy that your entire enterprise is about to adopt is the right fit.

Too light (but it may work for a startup), and your undertaking becomes inconsistent, priorities become ever-changing because there's no clear focus. The entire system is not reliable enough to deliver.

Too rigid (but it may work for a Fortune 500), and you may get in your own way with bottle-necking processes, decision-making by committee, waiting for an approval exit gate that never arrives, wasting time because the system is not flexible enough to deliver.

Where too much process is a hindrance (but may work for a large org) and too little is volatile (but may work for a fledgling company), start with some core principles that are key for your org and build from there.

An OPM at scale strategy could look something like this:

• Decide how projects in your portfolio are managed across your enterprise. That means an off-the-shelf OPM solution may not be where your answer lies—instead grow your solutions for areas like governance, change, prioritization and resource management, as organically as you can.

• Implement a few standard workflows that support delivery throughout a team and between teams. Are some processes already working? Keep 'em. Notice a couple gap areas? Partner with teams to design a workflow that solves your specific problem.

• Create consistency with standard, formal processes, but also allow project managers and teams the freedom to make good tactical choices.

• Focus on picking a few benchmarking criteria.

• Make space for continuous communication, provide visibility and support working toward improving the core you've got—not necessarily adding anything new.

At your next quarterly review, examine how your custom OPM framework is doing. Are you all still aligned on, not just the goal of your portfolio, but the goal of your OPM strategy? Ready to go bigger and start maturing your framework? Or instead do you need to scale back?

What experience do you have with implementing OPM to scale?

Want to see a fully baked standardized model, take a peek at PMI's Organizational Project Management Maturity Model (OPM3®).

By Christian Bisson, PMP

In my last post, I discussed why you should manage projects via project management tools rather than via email. Let’s imagine you’re making the transition—a wise choice, congratulations! But it may not be smooth sailing as you embed the tool into day-to-day team life.

This post talks about challenges you might encounter a long the way, and how to address them.

1. Cannot use the tool

Not everyone can pick up a tool and learn how to use it on their own. And more often than not, training given to people is not fine-tuned to each individual’s needs.

Some will struggle, meaning they will avoid the use of the tool and revert back to emails or other means to get their work done. In this instance, you might even be asked to stop using the tool yourself because others struggle.

Although abandoning the tool might seem like a quicker way of fixing the issue, it’s actually addressing a symptom, not a cause. Avoiding the use of the tool is not going to be beneficial to anyone long-term.

Instead, take the time to help anyone who struggles, or prepare customized training for your team members. Ask them where they are having trouble, and show them how they can achieve what they need to do.

2. Annoyed by notifications

Oddly, one recurring complaint of using a project management tool instead of emails is receiving too many emails. For instance, when people comment within a task, the tool might email once per comment.

There are two ways you can mitigate the amount of emails:

• Guide people toward their notification settings so they are configured to meet their needs. Some like to have lots of emails; others prefer to use activity feeds or a notification dashboard within the tool.
• A project management tool should not replace a conversation. Invite people to discuss issues in person or via a conference call instead of having 10 back-and-forth debates within an item of the tool.

3. Partial access or multiple tools

Many organizations work with more than one tool, which can be very effective in some cases. However, what often happens is that team members are confused because they do not know where to go to see their tasks. In addition, sometimes team members in other locations do not have access to the tool.

All this means the project manager struggles to manage all the work of a project since tasks can’t be assigned to everyone or tasks are split into different locations.

This can be tricky to deal with if the project manager cannot select tools and access. However, the objective is to have everyone on board use one project management tool only. This lets all team members know where to get the information they need and allows the project manager to have a complete view of the project in one place.

4. Email lovers

There are some who feel they cannot live without email. Even when the project management tool has all the information and properly archives it, some team members still want that information emailed to them. Project managers should not resort to sending information within the tool and also sending an email to that person, which is duplicated effort for nothing.

In these cases, it is important to show the person that the same objective can be met with the tool. Show him or her how to access the information easily and how to archive a project workspace if that is a long-term concern when closing a project.

By Christian Bisson, PMP

In the world of project management, you will encounter the “email philosophy” and the “project management tool philosophy” of how project tracking/communication should be done.

Emails can be an effective way to communicate or keep written documentation to refer to. Heck, I love emails. But ultimately, a properly used project management tool will be more efficient for your team. Here’s why:

1. Documentation Efficiency

Email might be a great way for you to track your written communications, but how properly it’s used and archived depends on the recipient. In contrast, with a project management tool, the “documentation” will be stored somewhere within a task or other type of item within the tool. Everyone can refer to it, and it should be easily found in the appropriate location instead of somewhere in someone’s inbox.

For example, I once took over a project from another project manager who used emails to manage the project. To help me get up to speed, the project manager had extracted a dozen emails and sent them over. I had to go through all those emails threads, most of which were out of context or outdated.

A better option would have been to have the relevant information within a project management tool where I could have reviewed the available information and known exactly who was doing what.

2. Task management

You could send someone an email listing tasks to accomplish, but unless that person replies with a status or you regularly ask for one, you will not get an update. If an update does come, only you and maybe others from the team will be aware, assuming they even read the email.

A project management tool will allow you to track all those tasks, with a proper assignee and status. It will be simple for someone to have all his or her tasks displayed and ordered in priority, including a description of each task/issue. In the meantime, the project manager can easily track the status of the project without having to constantly ask for one.

In my next post, I’ll talk about how to overcome challenges when switching from managing via email to managing via a project management tool. 

By Taralyn Frasqueri-Molina

A lot of things change when moving from traditional project management frameworks to agile ones. But what doesn't change (or shouldn't!) is how much and how often teams communicate. 

Agile frameworks don't actually require daily stand-ups or regular retrospectives. But you should consider adding some new trade tools and a few other staples to your project management toolkit if you’ll be working in an agile context. You may find that they quickly become essential to keeping communication flowing through your team—and your project on track.

Here's a short list of tools I've used on all of my projects.  

Sync-ups/Planning Meetings: This helps me start a project off right by making sure the product owner and execution team are on the same page. We set expectations, talk requirements and the direction for deliverables in areas such as UX, design, marketing.  

Daily Stand-Ups: Quick check-ins with the entire team help gauge project health and bring roadblocks to the forefront sooner rather than later. This is also where we address scope creep, taking note of good ideas that need more exploration before being included in the backlog.

Retrospectives: After each sprint and after each project, a retro helps the team ensure processes are working— and decide if we want to carry over those processes to the next iteration.

Wiki: These often get a bad rap but can act as an excellent centralized location for real-time documentation editing and sharing. In my experience, it can serve as a digital asset management (DAM) system for sharing web copy and design assets. While not a perfect DAM solution, it will do in a pinch.

Instant Messaging: Whether collocated or remote, teams sometimes need quick answers to questions—and a meeting can be overkill as a way to get answers. The challenge with instant messaging, though, is to make sure teams are on the same page about how and when to use an IM tool.

Email: This tool still reigns supreme when it comes to quickly keeping a lot of people in the loop about what's going on. Even if it's an email directing people to a wiki, it's still one of the best tools for mass communication. But maybe not for decision-making!

What tools am I missing? And do you find any of the tools mentioned particularly good or bad for certain kinds of communications? Share your thoughts below.