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
Soma Bhattacharya

Past Contributers:

Jorge Valdés Garciatorres
Hajar Hamid
Dan Goldfischer
Saira Karim
Jim De Piante
sanjay saini
Judy Umlas
Abdiel Ledesma
Michael Hatfield
Deanna Landers
Alfonso Bucero
Kelley Hunsberger
William Krebs
Peter Taylor
Rebecca Braglio
Geoff Mattie
Dmitri Ivanenko PMP ITIL

Recent Posts

3 Ways to Balance The Delivery Ecosystem

6 Steps for Improving Organizational Maturity

Debunking Six Misconceptions About Agile

3 Reasons Project Managers Are Like Jugglers

PMI + TED: Possibility Speaks

Viewing Posts by Christian Bisson

Free Your Team With Liberating Structures

By Christian Bisson, PMP

I recently had the privilege to participate in the 9th Montreal agile coach gathering. Along with meeting great people and having a chance to exchange ideas with them, I had the opportunity to learn about “liberating structures”, a concept developed by Henri Lipmanowicz and Keith McCandless.

Liberating structures are 33 alternative structures for facilitating meetings, work sessions or retrospectives. Unlike conventional structures, such as status reports or presentations, liberating structures are meant to distribute control of the conversation so that all participants are part of shaping direction. This ultimately helps everyone work together while feeling more in control. According to Lipmanowicz and McCandless, conventional structures are either too inhibiting or too loose and disorganzed to achieve this.

Within your organization, liberating structures can be used to organize and facilitate work sessions, retrospectives or other types of meetings. These structures range from simple and fast exercises to those suited for more structured and longer meetings, giving a diversified toolset for various circumstances.

One evening during the 9th Montreal agile coach gathering, everyone gathered into small teams, picked one of the liberating structures randomly, and took 25 minutes to understand and discuss it with the objective of presenting it to everyone else afterward within a three-minute timebox.

Our team picked “critical uncertainties”, which makes you focus on essential and uncertain realities, and then plan strategies according to different possible futures. Among brainstormed ideas, you need to identify the most robust strategies (i.e., the ones that would work with the most possible futures). You can then plan action items based on what was discussed.

Another one that caught my interest is “1-2-4-all.” It is simple and can be used in so many circumstances, yet it is efficient to help a group of people (small or large) communicate and share great ideas.

For anyone out there who is a fan of liberating structures, I’m curious to find out which ones you used, in what context, and how was the result. Please share and discuss!

Posted by Christian Bisson on: March 15, 2019 06:39 AM | Permalink | Comments (16)

Debunking 4 Misconceptions About Story Points

Categories: Agile

by Christian Bisson, PMP


Story points, while an essential component of agile, are often misintrepeted.
And that’s a problem, as story points are are a vital unit of measure to help
estimate user stories. And stories, in turn, help teams plan their next sprint.
When they’re misinterpreted, story points lose their effectiveness, and they
can even hurt teams because of how they are used.

For the sake of my examples below, I assume teams use the Fibonacci sequence.
Let’s run through a few common misconceptions:


1. It’s about the complexity.

Some teams will mistakenly focus only on the complexity of the user story,
as measured by the required level of training it takes to complete a given
task. If a task is simple but time-consuming, they will assign it a “1.”
This is misguided because in addition to complexity, story points also take
into account effort and risks.

It’s important to factor in all three of these aspects of user stories to make a
proper estimate.

2. It’s about the business value.

Simply put: no.
When prioritizing their backlogs or even deciding to move forward with a
user story, it’s important for product owners to understand that story points
have nothing to do with business value.


A “13” could bring no value while being costly, and a “1” could be a golden
opportunity (a.k.a. a “quick win”).


Some Product Owners assign a “Business Value” to user stories (for example: A, B, C), although not mandatory, it can be used along with story points to help make key
decisions about priorities.

3. One point is one day of work.

Story points are not days, nor hours—they are a separate unit of measure. If
using “days” to estimate user stories works well for your team, then by all
means keep going, but call them days as opposed to story points to avoid
confusion.


4. Story points can be used to compare teams.

This one is a dangerous trap, especially if used by someone who can
influence people below him or her. It’s important to understand that story
points are relative to each person. Even within a team, it can be a challenge
to align initially until they have a few user stories to compare with.

A “5” can mean something different for Team A than for Team B, so
comparing each team’s velocity gives absolutely no value whatsoever. In
fact, it can mislead you into thinking one team is more efficient than
another, which in turn might result in unjustified negative feedback or
pressure to “have high velocity.”


In Summary

Story points are a tool, and like all tools, they’re only as good as how we use
them. If we fall into common trap, using our story points to plan our sprints
will lead us to disaster. It’s important that every member of the team
understands the concept, and that you also take the time to educate anyone
outside the team who has influence over your work, such as upper
management or customers.


Do you know of any other misconceptions around story points?

Posted by Christian Bisson on: January 26, 2019 01:44 PM | Permalink | Comments (12)

The Traps of Textbook Scrum

Categories: Agile

By Christian Bisson, PMP, PSM

 

The Agile methodology is quickly becoming the standard for IT projects. More specifically, most organizations are using the Scrum framework to bring their software development to the next level. 

But it’s implementation often remains a challenge and that’s because Scrum is not one-size-fits-all, and if you follow the manifesto too rigidly you can fall into a few traps.

Here’s a look at two:

1. Lack of Team Experience

If you’re coaching a team new on Scrum, take baby steps. Imagine if you’re teaching someone to play basketball for the first time. You will most likely teach them how to dribble before you teach them how to dunk a ball.

It’s the same with Scrum. If you throw everything in the Agile Manifesto or Scrum Guide at your team at once, chances are the results will be poor, the team will be confused and ultimately they will not enjoy the methodology.

For example, when assigning complexity, start with T-shirt sizes (small, medium, large) instead of the Fibonacci scale. When the team grasps this concept well, adapt accordingly.

2. Potential Waste of Effort

An active sprint is considered sacred for a team. Its scope must not be modified, and any new requests/requirements should be factored into future sprints.

Be that as it may, sometimes there are extreme circumstances where the sprint must be stopped or modified due to new requirements.

For instance, say an amazing opportunity presents itself three days into the sprint, making the current scope of the sprint obsolete. Fixating on the fact that a sprint cannot change and having the team work for the remainder of the sprint on something confirmed to be useless would be a waste.

If this sudden change creates downtime for the team while the new requirements are written and refined, the team could focus on testing new technologies, or working on a proof of concept that could help with the new requirements.

Or sometimes a project faces issues and due to the importance of the client, those issues must be prioritized. People may be pulled out from one team to help another. That will mean that an active sprint’s committed scope may have to be reduced, which is when you have to put aside the textbook for the sake of the organization, and to help out colleagues in need.

Have you ever had to steer away from initial expectations for a project or team’s benefit? Share your story!

Posted by Christian Bisson on: December 23, 2018 02:47 PM | Permalink | Comments (6)

What is project success?

by Christian Bisson, PMP

 

Project success is typically defined as being completed within budget, schedule, and scope, and that has been imprinted so much in project managers’ mind that it blinds them to other important aspects that defines a project’s success.

Client Satisfaction

This aspect of project success seem to be more and more popular, and with reason, if clients are not happy, they will shutdown the projects, or proceed with another organization. If your project is on budget, delivered on time, and does exactly what it should be doing, but the client is so unhappy that they ceases to work with the organization, can you consider the project a success?

For example, if you focus so much on being on budget/schedule/scope, that you decline everything the client asks for without a second thought, chances are the client will not want to work with you long term. On the opposite side, giving everything the client wants and ending up late or 200% above budget is not an acceptable alternative. You or the team will often need to be creative to find ways to balance things out, and properly managing the client’s expectations is also key top this.

Project value

Another very important aspect of project success is the value it’s adding. A project that is doing what was planned, but ends up being useless, is not a success.

For example, if you create a great website, the client loves the design, the development phase had only few minor issues that were fixed rapidly so the team is happy, the project is delivered on time, on budget, and does what it’s supposed to do, however, users that go on the website are completely incapable of finding the information they need, and they end up always calling customer service instead, then is that really a success?

It’s important to identify right from the start what metrics will be used to calculate the project’s success, and tie those metrics to features of the website as you go to make sure a feature is not useless or solves an issue that has nothing to do with the project’s objectives..

Organization Satisfaction

The organization that has provided the services needed to make the project happen is also a key aspect to look at to define the project success, and unfortunately often due to lack of transparency from management, can be a challenge.

For example, there are projects that the organization’s management know they will lose money on, but for them it is considered a long-term investment to bring more business. If that’s not communicated, the project manager will see the project as a failure because it’s over budget.

It’s important to have visibility on the organization’s goals and expectations around the project in question.

 

 

What are your thoughts on the matter? Do you use other aspects to define project success?

Posted by Christian Bisson on: September 11, 2018 08:27 PM | Permalink | Comments (16)

Machine Learning Isn’t Magic

Categories: Innovation, IT, Lessons Learned, ROI

By Christian Bisson, PMP

Machine learning is one of today’s hottest tech topics.

It’s essentially a type of artificial intelligence (AI) in which you give your software the ability to “learn” based on data. For example, you probably notice how YouTube, Netflix, Amazon and many other companies suggests videos or products you should check out. These suggestions are based on your previous online actions, or those of other people deemed “similar” to you.

For some time now I’ve been working on projects that involve this technology. We often have clients who want machine learning even though they do not know if it’s even relevant to them. Since “everyone is doing it,” they want to do it too.

Calibrating a project sponsor’s expectations is often a good idea. While the automated services generated through machine learning may seem magical, getting to that point involves challenges—and a lot of work.

1. It needs quality data.

The machine will learn using the data it has being given—that data is the crucial starting point. The data that’s available is what drives how the machine will evolve and what added value machine learning can bring to your project/product. For example, if you are trying to teach the machine to recognize vehicles on images it scans, and all you can teach it with are images of small cars, you are not set up for success. You need a better variety of images.

The machine’s ability to learn is directly tied to the quality of the data it encounters.

2. It needs lots of data.

Once you have quality data, you need it in high quantities. If you can only provide the machine with the website behaviors of, say, hundreds of users per month, don’t expect it to have enough information to be able to recommend the best products based on user trends. Its sample will be too little to be able to be accurate.

3. It needs to be tested continually.

Once you have the necessary data, the journey is not over. The machine may learn on its own, but it’s learning based on how it was built and with the data it’s being fed. There is always room for improvement.

4. It’s costly.

As amazing as machine learning is, it is not cheap. So keep an eye on your project’s budget. Machine learning experts can command high salaries, and there is a lot of effort involved with researching the best approach—creating the models, training them, testing them, etc. Make sure the ROI is worth it.

Have you had a chance to work on a project involving machine learning? What challenges have you faced?

Posted by Christian Bisson on: July 14, 2018 08:59 AM | Permalink | Comments (11)
ADVERTISEMENTS

"We are ashamed of everything that is real about us; ashamed of ourselves, of our relatives, of our incomes, of our accents, of our opinions, of our experience, just as we are ashamed of our naked skins."

- George Bernard Shaw

ADVERTISEMENT

Sponsors