Viewing Posts by Christian Bisson
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.
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.
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 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.
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.
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.
If team members are constantly interrupted, their efficiency drops. You can help them focus in a few different ways:
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?