Voices on Project Management

by , , , , , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rex Holmlin
Christian Bisson
Taralyn Frasqueri-Molina
Jess Tayel
Ramiro Rodrigues
Linda Agyapong
Joanna Newman

Recent Posts

My 2018 Goals For All Project Managers

Project Methodology: Help or Hindrance?

Every Project Is a Change

In the Rearview Mirror: The Year in Project Management

A Guide to Perfect Planning

Viewing Posts by Christian Bisson

The Importance of Iteration

by Christian Bisson, PMP

We’ve all encountered them on a project or two: stakeholders that want everything right away.

The result of this rush is often lots of money invested, a tight schedule, negative impact on the quality and frustrated people. But, carefully planned iterations of a project can help avoid the negativities of rushed efforts.

Here’s why:

Minimum Viable Product (MVP)

A well thought out MVP is the first iteration of your project. It means planning for the smallest scope possible, keeping in mind that it still needs to bring business value.

Let’s say you’re building a website. In this scenario, you’d identify the main features your website should have — based on goals — and focus on those instead of spreading the effort on all the features that might seem great to have.

There are many advantages to the MVP approach:

  • It can be deployed much faster compared to the complete scope.
  • You can monitor your project in action (ex. Google Analytics).
  • You can gather valuable feedback from people who use it.

Room to Adjust

Since you haven’t spent all the budget on the entire scope — and you now have precious data gathered from various sources — you can plan based on facts rather than hypotheses.

For example, after the MVP is deployed, you might have planned to work on a new feature. However, if new data suggests that the main feature of your project is not quite user friendly and needs adjustments, you can prioritize the adjustment and quickly add more value to your project compared to adding a new feature that might be less important.

Deploy When Ready

The MVP is only the first of many iterations. Do not fall back into the trap of building everything before you deploy your first update. Using the example above, if the first feature is actively affecting the quality of your project, adjust it and deploy right away. That way you will gain the added value of your improvement right away.

Some might argue that deployments cost money so you shouldn’t deploy all the time, and it’s a fair point. But keep in mind that the cost of those well-planned deployments are negligible compared to all the budget you can waste on a misfocused effort or a wrong hypothesis.

Taking a step-by-step approach to project management is crucial to the long-term success of projects. How do you manage the iterative or MVP approach? 

Posted by Christian Bisson on: November 04, 2017 01:29 PM | Permalink | Comments (11)

A Scrum Master’s Duty

Categories: Agile, Teams

by Christian Bisson, PMP

A scrum master is an essential part of an agile team. However, it seems their role is often underestimated or misunderstood. In this article I’m hoping I can shed some light on the value they bring.

How People See Them

Here’s what I’ve heard over time:

Elves of happiness

Since scrum masters want teams to perform well, they want to make sure team members are happy. That sometimes makes others think that all scrum masters are trying to do is to make everyone happy without an actual purpose behind it.

Coordinators

Since scrum masters often talk to the team and gather information about the status of a project, they are often mistaken for coordinators—people tasked with giving a status report to the product owner or taking notes during meetings.

Useless

Some people simply have no clue what scrum masters do, thinking they are an overhead that could be removed without any impact because they don’t actually “produce” anything.

What They Actually Do

Help teams grow

One of the scrum master’s main tasks is to educate the team with agile principles, but also to help the team become self-sufficient. In a way, their main duty is to actually become useless as the team becomes more mature.

Scrum masters can do so by sharing agile knowledge and by coaching teams as they go through retrospectives where the team is motivated to talk about how they can improve.

Facilitate anything

There are so many different roadblocks that can reduce a team’s efficiency—whether it’s poorly defined requirements, inefficient meetings, lack of documentation or communication, or conflicts. A scrum master can help tackle anything that might slow down the team.

Keep the focus on the right place

Not being hands-on in projects allows scrum masters to have a different point of view that allows them to re-focus teams when needed. Whether it’s toward the developers and their commitment to the sprint, or product owners and their focus on a product’s vision, scrum masters make sure to remind everyone where their effort should go.

 

It can be hard to quantify a scrum master’s usefulness since they do not actually produce deliverables. But having experienced an agile project both with and without a scrum master, I can vouch for their role. They bring so much on a day-to-day basis to the teams they work with, which in turn brings quality products to clients.

Have you experienced working with scrum masters? What do you think is most important about their roles? 

Posted by Christian Bisson on: August 11, 2017 04:13 PM | Permalink | Comments (17)

Are You Documenting Smartly?

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!

Posted by Christian Bisson on: April 07, 2017 12:20 PM | Permalink | Comments (19)

How To Protect Your Team’s Time

Categories: Leadership, Teams

by Christian Bisson, PMP

All team members must make—and meet—commitments to keep a project on track. However, it’s the project manager’s job to foster the conditions that will allow the team to deliver on its commitments.

Here are three tips to help you protect team members’ time — and ensure they’ll have the bandwidth to keep their promises.

1. Trust your team.

It can be tempting to ignore team members when they warn that there’s too much work to be done in a given amount of time. You may think they should simply push through. But if the project manager doesn’t commit to realistic deliverables—and find backup when necessary—problems just compound.

Take agile teams. It they commit to more work in a sprint than they feel they can complete, it will only make matters worse when unfinished work passes on to the next sprint. But if they commit to less work and get it all done, you might be surprised to find additional work added to the sprint, since the team is performing better than planned.

2. Clarify requirements and objectives.

A team can easily lose time trying to get up to speed. As a project manager, you can reduce confusion and delays by reviewing requirements and answering questions at the outset.

For example, if you’re working on a project with wireframes or designs, you may ask a team member to complete a simple task, like display the product page.

The team member that commits to this could then deliver half of what you expected simply because he or she didn’t have the full picture. Perhaps he or she thought only the desktop version of the page was needed and didn’t bother with the responsive design as you had expected. If you review instructions before work starts, you’ll have the opportunity to catch these types of discrepancies.

3. Protect their priorities.

If team members are constantly interrupted, their efficiency drops. You can help them focus in a few different ways:

  • Avoid ad-hoc status requests. Plan status meetings (i.e. daily scrums) or ask the team to reach out to you when they need something instead of you interrupting them to ask what they need.
  • Insulate them from changes. Changes are to be expected in projects — and it’s your job to deal with them so the team can remain focused on their work.
  • Be the shield. If another stakeholder — for example, a senior manager — interrupts the team with questions or requests, insist he or she go through you to obtain 
Posted by Christian Bisson on: March 09, 2017 09:13 PM | Permalink | Comments (18)

The Reality Behind a Deadline

By Christian Bisson, PMP

A deadline is the project objective defined in terms of time. But on some projects (a lot of them, unfortunately) the delivery date is not necessarily realistic.

When projects get delayed, the obvious solution is to push back the deadline. But it’s not so simple for every project.

Here are a few factors to weigh before deciding how to move forward when facing project setbacks:

The Client Relationship

Assuming the agency runs client-facing projects, not internal products, this is typically the most important reason to deliver a project on time. Happy clients bring in more projects—and other clients by word of mouth.

Determining whether or not your client will react negatively to a project delay may depend on the cause of the holdup. Is the delay related to client actions, such as adding new requirements or delivering assets late? Or is it due to internal errors, such as poor estimating or planning?

Keeping clients happy also presents a sort of balancing act for many agencies. You have to keep clients happy because they bring in the money that runs the agency. But, on the other hand, you don’t want your team members so bogged down with additional requests and revisions that they become tired or frustrated to the point they will leave.

The Cost

Projects often have what we call hard deadlines, meaning the date cannot be changed under any circumstances. For example, in e-commerce, there are projects tied to holiday sales and, obviously, those dates cannot move. Missing those opportunities can have a drastic impact on sales. In these cases, it might actually be more cost-efficient to invest in more resources to speed up the project and have it ready on time.

The Big Picture

Delaying a project can have a direct impact on other projects, as well. Team members may be scheduled to move to another project once the first is completed, for example, so delaying that transition date can have a chain reaction on an agency’s planning. Talk to someone with a wide-angle view of the organization’s portfolio to better understand these potential implications.

There’s no magic solution for dealing with a delayed project. All you can do is balance the pros and cons and make a judgment call.

What factors do you typically weigh when deciding whether or not to push back the deadline on a delayed project? What advice do you have for other project managers facing a delay?

 

Posted by Christian Bisson on: January 28, 2017 10:21 AM | Permalink | Comments (2)
ADVERTISEMENTS

"Maybe this world is another planet's hell."

- Aldous Huxley

ADVERTISEMENT

Sponsors