Voices on Project Management

By Christian Bisson, PMP

For project managers, change is constant—inseparable from day-to-day life. And if you work in IT, the pace of change is only getting faster. Unfortunately, human nature makes us reluctant to change. So for project managers and others who want to make change happen, here are a few tips:

1. Help people adapt

No matter the type of change—whether it’s a new technology, a new process or a new methodology—the steeper the learning curve, the fewer people who will be onboard.

Help people adapt to the change with these approaches:

• Build tutorials: Any guide whatsoever will simplify the learning process. It can be very simple or more elaborate, depending on the size of the change. Avoid anything long and tedious. Aim for quick and simple to use, like cheat sheets or interactive tools.
• Offer help: Let people know that you (or someone else) are available to help them. Obviously, make sure it’s true, and appropriate help in a timely manner.
• Plan the change: People should be introduced step by step to the change instead of forced into it all at once. Going at a more reasonable pace will greatly reduce the fear.

2. Show how it’s helping THEM

This tip may not apply for all the changes we want to execute. But let’s say you want to change a tool that a team uses for projects. The team’s initial reaction might be skepticism or resistance.

You want to make sure that people are aware of how the changes are good for THEM—not you or management. In my example above, you could tell team members it’s going to make their overall work easier. They will have a more efficient tool that will quickly give them access to the information they need.

By focusing on that when you brief the others, they will also focus on that while they are juggling their emotions toward the change. As they fight their reluctance, they can remind themselves how the new tool will help them.

3. Ask “Why?”

This tip can be applied once reluctance is detected. It’s easy to insist on something or even to force it on people. But by simply asking why they are reluctant, you may learn that it’s because of simple reasons that can be mitigated. You may even find out that your idea is not as good as you thought, and you can adjust accordingly.

By asking why, rather than assuming you know how the other people feel (or trying to guess), you’ll receive valuable feedback.

Once a colleague was annoyed by new software we were using just because he was receiving too many notifications. I simply guided him toward the notifications preferences, and it made all the difference for him.

4. Don’t give up

Stay positive, and keep it up. The tips above should be repeated as needed.

Share  your tips and stories! I’m certain a lot of you are facing challenges with changes inside your teams.

By Christian Bisson, PMP

Agile approaches allow for iterative and flexible avenues to develop software. (It can be used in other fields, of course; I work in the software world.) When used properly, it can be an efficient way to adapt to changes in requirements and scope, and provide stakeholders with an up-to-date and ongoing list of deliverables to review.

Unfortunately, it’s a misunderstood approach that leaves many of us wondering if they’re really working in agile ways. Here are a few misconceptions I’ve encountered throughout the years.

Things just change names

My favorite misconception of agile is that terms suddenly need new names.

Meetings become “scrums” or “daily scrums”—even though the team is just having a regular meeting. A “week” becomes a “sprint”—even though there is no deliverable/release at the end.

Going faster is agile

Project managers sometimes “crash” a schedule to speed up project deliveries, knowing that it uses more budget in order to meet a deadline. Sometimes “crashing” is confused with “agile,” which is thought to deliver projects sooner and cheaper by having everyone start their work sooner than they would have in a traditional waterfall approach.

Having people start sooner and risk rework is still crashing even if the practice is called “agile.”

Stakeholders don’t have to be involved

Stakeholder involvement is a critical part of the agile approach. It requires them to be available and in constant discussion with the team. This prevents surprises and allows constant feedback.

The misconception I see sometimes is that a team can work “full agile,” with stakeholders only involved when they receive assets and go through their typical review cycles.

We’ll just “try” agile

Agile is not about trying out a new software. It’s a culture, and it involves everyone from stakeholders to the team. Some believe that a few people can “try agile” on a project and see how it goes, even though none of them worked in an agile environment before.

Scope and cost can be fixed

Although agile could work with a fixed cost, it is quite the trap. Agile assumes that what will be delivered is the work that the team was able to deliver in a set amount of sprints, and each sprint will cost a certain amount based on the team’s size (among other things).

This means that if a feature took twice the amount of time estimated because it was decided to create something a bit more complex, then another feature might be removed or budget will be added to compensate. However, if you keep the budget the same but still expect to deliver everything planned on day one, then this more complex feature is simply scope creep.

These are just a few examples of agile misconceptions. My bottom line: When I’m told stakeholders want to use “the agile approach,” I make sure to ask for a definition of agile.

Have you encountered other agile misconceptions? Share them below!

By Christian Bisson

The number of years a project manager has been working certainly gives you a clue about his or her ability. But this isn’t (and shouldn’t be) the only information you can use to spot a project manager who is a cut above the rest.

Below are a few tips to help you assess if someone really knows their stuff. Just as you’d adapt your expectations of junior project managers to their experience, use these tips to get a sense of how “experienced” or “senior” someone really is. I’ve recently put them to good use when a project manager was temporarily hired to take my place while I was out on paternity leave.

Ready to Ask Questions

The first sign is simple. A project manager who aims to do the job correctly will proactively ask questions when planning a project, instead of delivering an asset that is incorrect. Or, the project manager will deliver the assets but will clearly state he or she was missing some information and did what he or she could as best as possible.

If you receive an asset that is supposed to be ready and yet you need to revise multiple times, you’re probably working with an inexperienced project manager.

Organized and Responsive

Being organized is a typical quality used to describe a project manager, and it’s something that should also develop throughout the years. Assuming the project manager’s workload is reasonable, here are a few clues to help spot if the person really is organized:

• If he or she is managing multiple projects, are projects being prioritized properly?
• Are emails sent to the project manager acted on in a timely manner, or do you have to follow up on most of them?
• If simple, straightforward information is discussed, has it been noted or used properly, or has it been forgotten (for instance, a delivery date discussed that should be added to a schedule)?

Can Cope With Change

Change is part of project management, whether because of client requests or other issues that arise. An experienced project manager is able to adapt accordingly and drive the project forward. Ask yourself these questions about your project manager:

• Is the team properly made aware of the changes?
• Does the project manager remain calm at the prospect of change?
• Are issues met with a solution-oriented approach?

Past Jobs

This is the only tip that could help assess a project manager’s experience prior to working with him or her. Although it’s a vague indication, spotting the extremes can help.

• If project mangers worked at only one place all their career, it might indicate that they are used to the routine of that place and are inexperienced in anything else.
• On the other hand, project managers who seem to change jobs every few months might not be well-suited for this line of work.
• Also note that where someone worked means little; what really matters is what he or she did.

Have additional tips for judging a project manager’s abilities? Please don’t hesitate to share.

By Christian Bisson

Risk management is often overlooked. Most people think it’s simply additional costs; others think it’s secondary and can be put aside to prioritize everything else. Some simply don’t understand it at all.

Regardless, project managers should always push the team to do it, even if at first it seems like it’s more about educating than any actual risk management.

While doing just that recently, though, I stumbled onto a new point of view I didn’t see coming: Risk management is “negative.” The rationale behind this view seemed to be that it makes us focus on what could go wrong, when we should be managing the project without thinking about potential problems.

I can’t deny that being positive is important for every aspect of one’s life. But I couldn’t disagree more that thinking about what could go wrong is negative. If anything, risk management is a positive way to work to make sure the negative stays far away from your projects.

Risk management is also about focusing on the positive risks and how to embrace those opportunities, although that part of risk management is often overlooked, unfortunately.

Have you come across similar point of views around risk management?

“Creative” is rarely a word used to describe project managers. Typically, they’re called “organized,” “good communicators,” etc.

A colleague of mine inspired me when he said that a good project manager is a creative one. I was confused at first, but his explanation made sense. To be able to take advantage of great opportunities as they present themselves, a good project manager needs to be creative with the scope and the budget as the project evolves.

In other words, project managers shouldn’t automatically respond: “No, we can’t, it’s out of scope or budget.” Instead, they should say: “How can we make it work?” Genius!

Every project manager is guilty of refusing a great idea when the team comes up with something out of scope or budget. It’s easy to say “no,” but it’s a lot more rewarding for you, the team and the project to find a way. That’s where you get creative!

The first solution that generally comes to mind is upselling the idea to stakeholders and asking for more funds. This could be denied, or it might not even be an option if the budget is fixed.

Another solution is to reduce another part of the scope or even remove it completely to accommodate this new idea. There are often “nice to haves” on projects, and they can be traded for better ideas. That’s where the new idea needs to be sold as more efficient than what’s being removed.

Other solutions can be outsourcing to reduce some costs, or even pulling some strings if needed. And you know what? You don’t have to do this thinking alone—give your team the chance to contribute ideas. You might find out that if some features are slightly different, you can save effort here and there, and then you are able to transfer some budget somewhere else.

The key point here is leaving “no” as a last resort, and asking yourself and the team: “How can we make it work?”

How are you creative with your projects?