Viewing Posts by Christian Bisson
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.
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?
by Christian Bisson, PMP
When a new person joins the team, there’s always a bit of a learning curve. But when teams fail to prepare new members, it takes even longer for them to provide efficiencies and improve performance.
Here are three training tips to help new recruits hit the ground running:
1. Don’t Put Trainees In Control
Being available to answer questions isn’t a sufficient way to train new team members.
While knowledge is transferred when you answer a question, new recruits can only ask about issues they’re aware of. This means they’ll often make mistakes that could have been avoided.
Rather than let team members learn things the hard way, share important information before questions are asked—and remember that details matter. For example, project briefs are done differently everywhere, and it’s not always clear who should be included if no one has been specified. A new team member might not think to ask if he or she has sent briefs a specific way at previous jobs.
2. Create an Onboarding Plan
Don’t make new team members chase people down to discuss processes or protocols.
I once joined a team where I was told to set up meetings with a dozen different colleagues so they could explain how they work. I didn’t really know how the conversations would turn out, but I expected the others would be prepared to meet with me.
The result was a bit surprising. The list of people I was supposed to meet with was outdated—several were no longer with the company—and those who were still around expected me to lead the meeting since I had set it up (which made sense). So they didn’t quite know what to say.
This experience was an eye opener. To make new members feel welcome, teams should plan onboarding discussions in advance and have information ready to share.
3. Take a Phased Approach
More often than not, generic training sessions bore and demotivate people, wasting everyone’s time.
Instead, training should be relevant to a person’s role and immediate needs. For example, not everything that a new team member should know will be relevant on day one. If you give them information they’ll need a few months down the road during onboarding, chances are they’ll have forgotten everything when that time comes.
Training and knowledge sharing should be done gradually. The gaming world offers a useful example. Many games have ongoing tutorials where bits of information are shared throughout gameplay, requiring the player to practice a new skill right before it’s needed. This approach maximizes the learning experience and keeps training from becoming tedious. It makes lessons easier to absorb and more likely to be remembered.
Training is often thought of a secondary need for new team members, being conducted as time allows—which might be never. How do you make time for training on your team? What type of knowledge transfer do you prioritize?
by Christian Bisson, PMP
The project manager role is often underestimated or inaccurately interpreted. Because organizations can have different definitions of what project management means, there is sometimes a lack of clarity around the role, especially for non-project management professionals. In this type of environment, people fall back on basic stereotypes.
If you find yourself typecast in one of these roles, take heart. You are not alone.
1. The Note Taker
One of the most stereotypical expectations of project managers is that they’ll be the meeting note taker. I’ve experienced this time and time again. During a large client presentation, for example, one of my colleagues was asked if he would be taking notes. He replied, “Well, I have a project manager for that.”
Yes, project managers take notes. But they shouldn’t be the only ones doing so. Meeting attendees tend to focus on the notes that directly impact their work. A designer, for example, will focus on conceptual and visual comments, while a developer will focus on features and functionalities.
Furthermore, if the project manager is leading the meeting it will break the meeting flow if he or she is also responsible for note taking.
2. The Meeting Organizer
Project managers will often be expected to set up meetings—and to a certain extent, that makes sense. For large meetings, such as internal presentations or milestone check ins, it makes sense to have the project manager take care of the planning. It allows him or her to rally everyone and set expectations for the meeting so the team can come in prepared.
But there is a line.
Teams shouldn’t expect project managers to organize meetings when they just need to gather for a brainstorm or a quick chat. Sadly, it happens. For example, I was once asked by a colleague from another office to book a meeting so that he could talk to another colleague that was sitting just 10 feet (3 meters) from him.
Project managers should encourage teams to be responsible for setting up those smaller meetings or one-on-ones themselves.
3. The Accountant
There is a misconception that the project manager is the only team member who should care about budgets, or worse, the only one that should be responsible for a budget’s health. This mindset is tough to change because it’s true that a project manager’s role, amongst other things, is to manage the budget.
However, the project manager cannot take everyone’s actions on his or her shoulders — and it wouldn’t be fair to expect that. If a feature was estimated at 50 hours and the team took 100 hours, it takes collaboration to fix the negative impact to the budget or schedule. The team must warn the project manager, everyone must discuss solutions, and then the project manager should take the appropriate next steps with stakeholders, etc. Obviously, this should be done as proactively as possible, not after the fact.
To think that no one should care about the budget, and only project managers should fetch this information and “figure it out” on their own is absurd. Yet, it’s a common expectation.
Have you found yourself in any of these scenarios? What other project manager stereotypes have you faced? How do you deal with these misconceptions?
By Christian Bisson, PMP
My last post about change stuck with me, so I want to revisit the topic by focusing on organizational cultural change here. Culture change means implementing new habits, new ways of thinking, new ways of working and so much more.
It presents a major challenge.
Why? Well, it’s more than processes, tools or documents—creating an organizational culture means changing people. This is as challenging as it gets.
When you’re looking to implement a culture change, here are few items to consider:
1. It takes time.
Most people will expect cultural changes to take a max of a few weeks, which is generally unrealistic. To level set expectations, share a roadmap of your changes.
The map should include high-level milestones of what the change will entail — training, meetings, etc. Then specify the objectives so people are on the same page as to why this is being implemented.
The roadmap will ultimately show that the changes are under control. It should mitigate any concerns or problems people will imagine.
2. You’ll need support.
A culture cannot be changed by just one person. There needs to be buy-in and it must be obvious.
I once had to implement daily Scrums with about 15 people, all of whom were accustomed to daily Scrums being long, painful meetings.
Changing that perception to one where meetings would last less than 10 minutes, where people would be on time, stand up and commit to the work they would aim to accomplish, was a challenge. I started by seeking out the colleagues in the group who were already on board with the change.
These early adopters helped me push others to stand up, be on time and ultimately helped keep things rolling when people went on tangents or brought up items out of turn. They were the first to jump in and “commit” to tasks rather than just saying whatever to get the meeting over with. It created a snowball effect, and we soon had efficient 10-minute meetings in place.
It’s a small example of a culture change, but it shows that having buy-in made all the difference.
3. Seek feedback.
All team members react different during a culture change. Some will let frustration accumulate and burst when it’s too much, others might complain as time goes, others will be constructive, others will never share, etc.
You want to take control over that by welcoming feedback, as often as you can, from as many people you can. Obviously, don’t talk to everyone everyday. Use your judgment — for example, you might want to talk to those colleagues impacted the most every week, while speaking to others only monthly.
While more time-consuming, gathering feedback from people is better done one on one. It gives you a chance to connect with the individual. If you speak in large groups, the majority of people will remain quiet while others take over.
How have you tried to implement changes to your organizational culture? Share your stories and your tips!
By Christian Bisson, PMP
Standardizing project management across an organization is often met with resistance, as teams are typically eager to customize their efforts based on how they feel is the best way of working. But while there are often adjustments that must be made on a client-by-client basis, there are many benefits to creating a consistent project management experience no matter the endeavour.
A project manager’s life can go from slow and steady to chaotic in a matter of minutes. If you have a common way of working it is easier for colleagues to grab your project for a day and coordinate while you focus on other—often more urgent—concerns.
For example, if your schedule is built using the same tool or template as your coworkers’ projects, opening it up to figure out what’s next is easy. It also keeps your colleague from messing up your well-organized plan, thus making it harder for you to jump back into the project when you’re able.
Shorter Learning Curves
When you hire a new project manager, he or she must learn how the company works—from clients and colleagues to tools and processes—before they can be efficient or add value.
If project management is standardized, it drastically reduces the learning curve for the new hire.
Cooperative Continuous Improvement
For anyone that reads my blogs, it’s quite obvious I’m an advocate of continuous improvement. The best way to do this is by working with other project managers, sharing ideas on how to improve our way of working, our tools, our templates, etc. Having multiple sources of feedback allows for better ideas to emerge and faster fine-tuning.
This is generally overlooked, however, if everyone works in a silo, doing his or her own thing.
Better Client Experience
If a client works with more than one project manager at the same agency, it creates a better experience when documents look the same across projects or communications are handled the same way by different project managers.
What do you think are the key benefits of standardizing project management across organizations? What have your challenges been? I look forward to discussing.