Nick Wilkinson

Can of Worms

Sun, 09 Apr 2023 00:00:00 -0700

Do you ever get afraid on client calls?

If you’ve been working in a client-facing role for a while you’d probably tell me that you don’t. Nervous, maybe, on occasion. But not afraid. That would be my answer, too:

➔ When we tripped over a shocking lack of alignment among the client’s leadership team mid-way through the project, I was concerned.

➔ When it became clear that no one really knew if the client had either the expertise or the funding to carry out their Big Idea, I was apprehensive.

➔ When Major New Client’s VP parachuted into our weekly sync, which they had never attended before that day, to make a big out-of-scope demand that would derail the timeline and budget, and we didn’t push back so we could “score some points”, I was annoyed.

But afraid? Feels like too strong a word for it. We’re experienced professionals delivering professional services, after all. We‘re not supposed to scare easily, right?

And yet, from time to time, there’s something that keeps us from having the conversations we know we should be having in order to prevent problems and keep our projects strong. Sometimes, being able to spot a Can of Worms off in the distance isn’t the challenge—doing something meaningful about it is.

Mind you, a lot of things might be in that Can of Worms: losing the deal; eroding the client’s trust in the team’s ability to deliver; goodwill discounts; personal embarrassment; maybe even veiled threats of potential legal action. So, in a word, that Can of Worms is filled with stress. And since stress can make us say and do weird things we know we shouldn’t, it’s useful to look at how we typically respond to stress as a step toward diffusing its power over us.

Fight, flight, freeze, or fawn

Early in my career someone told me there’s a lot to be said about a person who sees danger and decides to run toward it. That really stuck with me, and it embodies a general understanding of how people might respond to a given threat—by either facing things head on (fight) or by removing themselves from the situation altogether (flight).

In client services, most of the time we face things head on, which is typically the ideal response—that’s an interesting idea; here are some trade-offs to consider. Sometimes we flee—that’s an interesting idea; I’ll get back to you. But while Fight and Flight can be reasonable and effective responses depending on the situation, they’re only half the story. Two lesser-known but more troublesome stress responses are Freeze and Fawn:

To freeze is to see a Can of Worms and do nothing—that’s an interesting idea… *hopes it dies due to a lack of inertia*. Maybe the problem will go away on its own? Maybe I’m overreacting and it’s not really a problem? There are a lot of ways to rationalize doing nothing, but more often than not, doing nothing only makes the problem worse. Lucky breaks do happen, where situations somehow fix themselves, but luck isn’t a great strategy for managing client expectations.
Fawning is telling the client what they want to hear in order to avoid upsetting them—that’s an interesting idea; it’ll be a squeeze but… we can get it done on time. You can’t get something for nothing in projects, so fawning always results in a bad trade-off—swapping a problem now for a problem later, swapping the fear of maybe upsetting a client for the reality of definitely demoralizing your team. Although fawning might make a client happy right now, they’ll certainly be less than happy later when you’re forced to explain why you can’t come through on your promise.

Fawning is insidious, particularly when working with demanding clients who have hard constraints, because it can hide so neatly in our blind spots and general desire for either ourselves or our firm to be liked. But even “easy” client relationships can get to the point where we fawn from time to time and we don’t see it happening until it’s too late.

So how can we improve our stress response when working with clients?

Can openers

The Can of Worms is a wily adversary that demands respect. Unless your projects are all an unbroken boulevard of green lights, having a few go-to techniques for increasing the likelihood of success when trouble’s afoot can be helpful. Here are three that have worked for me:

Stop. Breathe. Think. Act. In SCUBA diving you learn that launching yourself into the fray when there’s an emergency is a recipe for disaster. Instead, you need to settle yourself down, take in the situation, and only then step in to help. This is equally applicable when a Can of Worms has been spotted.
Flight, then Fight. Would it be better if you could always give the client an authoritative answer on the spot? Sure. Do you have to? No. When a client tells you something that lights up your Spidey senses but you’re unsure of what to do, it can be perfectly reasonable to ask questions, tell them you’ll get back to them (and when), gather your thoughts on your own time, then come back prepared for the next conversation.
Introspective retrospective. If addressing the Can of Worms consistently and successfully is a skill you want to master, running a mini retro (by yourself or as a team) can be informative. Asking: “what was the situation, what was my response, what was I most worried about, what should have been my response” can help identify the gap between where you are and where you want to be.

Sometimes even doing a quick “am I fawning?” check after a thorny client interaction can be enough introspection to point you toward a more resilient path for your project.

Facing a Can of Worms takes practice, experience, and courage, but it’s important work that's ultimately in the best interests of your client. Just remember: there’s a lot to be said about a person who sees a Can of Worms and decides to run toward it.

So You Want to Hire a Digital Project Manager

Wed, 11 Nov 2020 00:00:00 -0800

Hiring people when you work at a smallish company: always time consuming, often frustrating, generally ill-defined. It's kind of a drag. And yet the outcome holds so much promise—a stronger team, more time to focus on priorities, an influx of other-ways-of-doing-things that helps inoculate your work culture against stagnation.

This is no small decision that you're about to make. Not only are you about to alter the fabric of your organization, you're about to change the course of someone's life.

As if that isn't enough pressure, I believe that hiring a digital project manager for agency work is especially difficult because DPMs generally need to weave together a broad range of perspectives and expectations from technical people, artistic people, business people, and clients. These skills can't be learned from a certification process. When looking for a digital project manager, I'm hiring for temperament.

The process

There are no short cuts, and no matter how carefully we craft our ranking spreadsheets and Kanban boards, the hiring process will never be objective. Don't be fooled by the promise of automated, "bias-free", AI-enabled hiring—it's modern-day phrenology. Hiring people is—and should be—hard work, and if all goes well, the potential payoff is so much more than the sum of its parts. Despite the challenges, hiring a DPM is like any other project: first figure out what success looks like, then figure out how to get there.

Defining success can be tricky. Aside from the basic table stakes required to work productively as a DPM in an agency environment—client-facing experience, professionalism, attention to detail—for me, success looks like finding candidates who are:

Engaging communicators. Candidates should be able to tell a concise narrative about their career and how life led them to applying for this job. Real life is messy, but a good PM must be able to extract a cohesive story from a jumble of facts.
Competent negotiators. Everyone wants something from a PM—time, people, flexibility, favours. Candidates should have experience standing their ground while working toward a win-win outcome.
Humble. We all make mistakes. We don't always have the right answers. We all get nervous sometimes. It's more effective to acknowledge awkwardness directly and with humility than to willfully ignore an elephant that just walked into the room.
Curious. Successful DPMs are part-time students, part-time sleuths, part-time journalists, and part-time social scientists.
Kind. Because I just finished watching season one of The Mandalorian, I now believe there are two kinds of PMs—those who immediately try to assert their primacy when stepping into the cantina, and those who understand the difference between aggression and strength. Aggressive PMs are toxic and fizzle out fast. Strong PMs understand the power of kindness, which engenders trust and yields great work over the long term.

Your list might be different than mine, but defining the broad intangibles you're most interested in shines a light on the kind of filter you should be using in your deliberations while you review resumes and speak with candidates.

The resume review

Does an applicant's resume look like an exercise in keyword stuffing, or have they painted a clear picture of who they are and what they've achieved? Are their accomplishments grounded in enough context to mean something to you, or is it all "in my role at GeneriCorp I increased operational efficiency by 5000%". If an applicant for a project management position can't communicate an easy to follow, meaningful narrative about their own lived experience when employment is on the line, they're probably not going to meet your expectations when trying to communicate the nuances of project challenges to clients.

The one-on-one call

After shortlisting applicants at the resume review stage, I reach out to each individual to schedule a 20 minute, one-on-one call. My approach to these conversations is that if a basic human connection can't be formed over those 20 minutes, we're probably not a great match for each other. I usually start with some softball questions—tell me more about: your experience, a situation where you handled conflict, etc—but these are just ice breakers. If an applicant says something unexpected and interesting, I'll ask follow-up questions. There's a school of thought that says every candidate should be asked the same questions to standardize the evaluation process. But for me, and in the context of hiring a DPM, that produces a series of super-boring Q&A sessions that don't give applicants an opportunity to shine.

By facilitating a free(r)-flowing conversation, both sides can let their guard down (at least a bit) to hopefully learn more about the human on the other end of the line—their motivations, their aspirations, what they feel is important to bring up in this moment. It makes room for unexpected and interesting things to happen, and hopefully they will. A conversational approach can be an effective way to get insight into a candidate's comfort with communication, negotiation, kindness, curiosity, and humility (or whatever's on your list), and to get a sense of whether or not you think your organization will be the right move for this person.

The team interview

I wish I could say that if a candidate scores at least 7.3 on the kindness-o-scope they'll be selected for a team interview. But your decision about who you'll speak with at this stage will come down to your instincts and the type of position you're hiring for—a seasoned leader who will shape your organization from a high-level, a strong tactician with new (to you) ideas, a junior-level PM who's hungry for experience, etc. From the one-on-one interview, can this person communicate well? Does it seem like they could negotiate effectively? From the stories they tell, do they seem kind, curious, humble? Do you think they'd add a new perspective to the work your organization performs?

The team interview is your chance to fill in the blanks and gauge whether the person you spoke with earlier matches up with the person who's sitting in front of you now. Bring in at least two other colleagues for the team interview to get their perspectives and to see how the candidate communicates with them—does the candidate address everyone in your group equally? Is the candidate exhibiting the same qualities that piqued your interest in the one-on-one? If not, why might that be?

After the interview, does your team think the candidate meets the definition of success that you mapped out at the start? If you're not sure, this doesn't have to be the end of the road. Everyone has off days. If it's not clear whether a candidate should be selected or not, why not reach out to them to meet up for an informal (remote) chat and discuss the position further over coffee?

The final cut

I admit that the process I've laid out in this post is vague and entirely subjective. I don't believe the process of hiring a DPM can be fully quantified. After all, it's a very human process—messy, biased, and unpredictable. And I believe that's what drives our desire to control it. We're afraid of the unknown and of making a mistake. Based on the incomplete and probably inaccurate data that we have, how do we know that we're making the right decision to hire someone (or not)?

We don't.

In this moment, before you make a hiring decision, you can never be entirely free of unknowns. And, in a way, it's freeing to understand that the unknowns can never be eliminated. No one knows more than you about the candidates you've reviewed. There is no one more expert in this moment that can make a better decision than you based on the information you've collected.

You might end up rejecting an excellent DPM. That's ok. Stay connected with your standout candidates on LinkedIn in case an opportunity to work together presents itself in the future.

You might hire someone who ends up not working out. That's ok, too. Talk to your colleagues about it and learn as much as you can from that experience.

What matters most throughout this ambiguous, human journey toward hiring a digital project manager, is that you don't forget your own humanity along the way.

Time Sheets, the Common Good, and JJ Bean

Sun, 02 Feb 2020 00:00:00 -0800

I hate time sheets. Filling them in is mind numbing, and they make me feel like I'm living in a surveillance state—every portion of my work life reported, categorized, reviewed. I've certainly got nothing to hide, but time sheets still make me feel micromanaged and self-conscious, like I'm not trusted to allocate my time appropriately. Also, they're kind of a hassle.

The only thing that makes me feel emptier than filling in my own time sheets is having to remind other people to fill in theirs. As a project manager, not only am I a prisoner in this panopticon-like arrangement, I'm also a guard.

But.

There’s a reason we fill them in, right? “If you can’t measure it, you can’t improve it”, says Peter Drucker. Time sheets aren't only a tool for figuring out if we’re on budget for a given project, they're also a rich source of historical project management analytics. They can help us answer questions like:

Typically, how soon after kickoff are we starting development on our projects, and how does that match up to initial plans? If late starts for certain phases of our projects is a trend, we need to investigate the habits behind the numbers.
How much time did we spend on UI design across all projects in 2019 as a percentage of total project time? Is that percentage relatively consistent across similar projects? This insight could help us estimate future projects.
Across all projects, how accurate are our estimates? For what kinds of projects are we estimating well and where are we weak?

Time sheets have a story to tell—ask the right questions and they’ll help point out our blind spots and our strengths. Measure, improve.

Rallying the troops

But if it can be hard for a project manager to come to terms with the effort required to fill in a time sheet, how are we supposed to convince the rest of the team that documenting their time is worthwhile? I’ve found explaining why we fill in time sheets, and making that explanation as concrete as possible, gives the team a common cause.

If you’re working in a client services-based agency, chances are your time sheets are critical to the wellbeing of your organization. If you're trading time for money on at least some of your projects, every hour that’s not recorded properly is an hour of billings that’s not going toward salaries, rent, benefits, or that cheesy bread everyone liked so much at the year-end party.

Put time sheet slip-ups into concrete terms—for example, in my case: one week of misreported time for one person can total the entire company's software subscription budget for the year—and your team will have a deeper understanding of the importance of pulling together on a mundane task for the common good.

And if that doesn’t work...

Try cookies. Give the team a deadline. If everyone has their time sheets completed by then, everyone gets cookies (or whatever treats your team loves). If any one person doesn't get their time sheet in by the deadline (within reason), no one gets cookies.

Both of these approaches work pretty well. So even if I still feel like my team and I are being surveilled a little bit through our time sheets, at least everyone knows they're generating valuable project analytics and helping to make sure the company stays afloat.

But really, it's about the cookies.

PS: If you're a PM in Vancouver or Toronto, I recommend checking out the cookies at JJ Bean. I have my favourites, but they're all good.

Zen and the Art of Driveway Repair

Wed, 15 Nov 2017 00:00:00 -0800

Without saying a word, my grandpa taught me the fundamentals of change management when I was 12 years old. We were standing on my gravel driveway at the top of a hill, and it was raining.

The rain cut deep grooves in the gravel as water flowed down the slope, and I knew I’d be doing a whole lot of raking to repair that damage once the ground dried out. But my grandpa had built highways his whole life and knew there was a better way. He had poured decades into the Coquihalla, Hope-Princeton, and Alaskan highways, and the sum total of that grit and hard-won know-how was now laser-focused on helping me out with my chores. My gravel raking days would soon be over.

But I didn’t understand why we were just standing there getting soaked and not talking—12-year-old me was crazy excited for a major earth-moving project. My grandpa, on the other hand, was calm and quiet, in an almost meditative state, watching the water flow in and around the gravel down the slope of the hill.

Observe and Be Still

Even at that young age I could tell that my grandpa was deeply in tune with forces that I wasn’t aware of. Looking back, I now understand that my grandpa was taking stock of the situation as objectively as he could—the problem, his team (water, gravel, the hill, and himself) and their attributes, and the desired outcome. Everything else was shut out.

By working toward a state of inner tranquility despite the damage unfolding in front of us, he was able to keep assumptions and knee-jerk reactions at bay long enough to see his team for what they were without bias, and for what he knew they could be. It didn’t matter that we were cold and wet, that repairs were going to require yet another round of labour-intensive gravel raking, or that Mom wouldn’t let him just pave the damn driveway.

None of those things were urgent in this moment. Quiet patience helped him set these issues aside temporarily so he could enact the change required to deal with the situation in front of us.

Understand Your Team’s Dynamic

Looking at the ground, my grandpa saw disharmony. Each component in the system was playing a part, but none were playing their parts together. Water just wanted to flow downhill and didn’t care which route it took as long as it was easy. Gravel was capable of contributing more structure to the team, but lacked the right support to stand up for itself when it needed to. The slope of the hill was ushering water in the right direction, but wasn’t able to provide specific, constructive guidance.

Making these observations took patience and experience. A more seemingly decisive action would have been to pay someone to pave the driveway or to install a network of drainage pipes down the length of the hill. But these solutions would have completely ignored the team’s existing potential. Starting the process by ignoring the existing state of the system would have introduced more disharmony in the form of added cost, complexity, and future frustration.

Take Thoughtful Action

After spending far too long standing still for a 12-year-old, my grandpa picked up a shovel and fashioned a berm across the width of our L-shaped driveway, right at the elbow. He then handed me a draw hoe and we dug a trench all the way down the hill along the downslope edge of the driveway.

Water was now ushered toward the berm by the slope, which had enough support to stand up to erosion. The berm guided water to the trench where it flowed downhill beside the driveway without causing any damage. By making two simple changes that leveraged the team’s natural tendencies, my grandpa was able to create mutual purpose and harmony in the system.

To me it looked like magic.

Inspect, Iterate, Maintain

My grandpa’s berm-and-trench solution was still working years later when I left home to study at university. For me, most importantly, hours of back-breaking repairs after every heavy rainfall had been replaced with just minutes of trench inspection and minor maintenance.

Now that I’m a project manager and often responsible for introducing change to the teams I work with, these lessons of patience, objectivity, and mindfulness have really hit home. My grandpa, the quintessential workman, would have been a little disappointed that I became a “manager”. But I think he would be happy to know that I was paying attention to what he was up to that day even when it didn’t look like he was up to much.

Enter the Project Log

Tue, 26 Sep 2017 00:00:00 -0700

Friday, 10:32am: Client Call Debrief

PM: Hey gang, we’ve got a problem. I just got off the phone with the client and they’re pushing back hard on revision request #3. I reminded them that we all agreed to cut #3’s functionality in the quoting stage, but that was nine months ago, and apparently Frank, when he was still on the team, got confused and promised we’d do it. All of the client’s feedback for the past several months has been based on the assumption that #3 is in scope.

Google Doc: Looking through past meeting notes... Frank hasn’t been on the team since... March, so the miscommunication probably happened before then. Kristi took over for him.

Calendar: Frank just left on vacation for two weeks and isn’t answering email.

Slack: HAHAHA KRISTI’S FUNNY SHE SAID SHRUG EMOJI

PM: I don’t remember Frank making that promise either. Drive—can you pull up the quote and requirements doc?

Google Drive: Sure thing. There’s no clear-cut answer here, though. The language is a little too vague.

PM: Gmail—can you pull up messages sent to the client from between January and March where Frank was included?

Gmail: No problem! Here are 16 threads each containing an undetermined number of messages that may or may not be relevant. Some of them are from the time period you specified.

PM: (exhales slowly) Alright. We need to know what happened and when to make sure nothing else has been miscommunicated to the client, and we need a plan for minimizing the impact on the project. But: there’s no one around who I can ask for more info, and there’s no documentation other than this pile of email that I’ll need to sift through and organize. This isn’t how I wanted to spend my Friday.

Friday, 3:12pm: Team Check-in

PM: How are we doing?

Google Doc: We’re on page eight of the report. It’s clear the client’s assumptions had shifted by the week of February 27th. We’re getting closer!

PM: Jira—can you tell me if there was a requirements change on issue 273 or 274 around that time?

Jira: Probably?

PM: ...

Slack: LOOKATME!!

PM: What is it Slack?

Slack: HAHAHA ANIMATED GIF FROM JAMES

PM: (sighs) while I’m here... Slack—any messages from Frank from around Feb 27th?

Slack: HAHAHA MY SEARCH IS TERRIBLE

PM: ...

Project log: Hey there.

Gmail: Who are you?

Project Log: I’m a Project Log. I aggregate all of the important updates and decisions that happen over the course of a project. The result is a timeline of who did what and when that you can refer to in times like these to pinpoint past problems more easily. I can also remind you about the general state of your projects when things get especially busy. I’m helpful in project reviews, too.

Jira: Pffff.

Gmail: So you can summarize emails and issue ticket updates automatically? Doubtful.

Project Log: Of course not. I’m a simple list the PM keeps of tweet-sized updates. When a decision gets made or there’s a status change, the PM jots down a short update summary, the date and time, and anything else that’s relevant. Links to documentation about more substantive updates can be added, too.

Jira: That sounds incredibly time consuming. The last thing the PM needs is to maintain yet another system. Things move fast. You can’t expect the PM to stop everything and maintain a list, or remember to make an update with enough detail after the fact. This is busywork for someone who’s already got way too much to do.

Project Log: Maybe. I’m definitely more art than science. It’s like maintaining a to-do list—the process is as light or as heavy as you want to make it.

Slack: HEYLOOKATM....

PM: (enables Slack’s Do Not Disturb mode) Let’s park this for now. Gmail—keep feeding me emails so we can finish putting this report together.

Friday, 6:43pm

Gmail: Ok I think that’s it. The report was just shared with Kristi and we’ll discuss the plan with leadership on Monday. High fives!

PM: Hold on—I’m glad we have a plan, but I can think of at least three significant problems that landed us in this situation that we need to sort out:

Why did Frank think #3 was in scope?
Why didn’t I flag this as soon as I saw Frank’s email to the client?
What improvements can we make to our contracts and kickoffs to help avoid situations like this?

Gmail: Use... Basecamp?

Jira: (rolls eyes)

PM: Maybe, but these are process problems, not technology problems.

Project Log: Hey there.

Jira: Ugh.

Project Log: Let’s be honest—you didn’t flag Frank’s email when you saw it because you weren’t paying attention. No one was. You’re getting a hundred emails and other notifications every day...

Slack: HAHAHA DANCING BATMAN GIF

Project Log: ...so it’s no wonder a few things fell through the cracks here. I’m not saying I can solve all your problems, but if you make me a part of your team, I’ll force you to pay attention because you’ll need to write down the important stuff every day.

PM: How would we start?

Project Log: Make a new spreadsheet with three columns...

Google Sheet: ’Sup.

Project Log:

Project name
Log entry date/time
Log entry text

That’s pretty much it. If you want to get fancy, you can create extra columns for tracking whether a log entry describes a status update or a decision, to link to relevant documents, or to track anything else that’s important to your process. Just remember to keep your entry text bite-sized—say, 250 characters or less.

Jira: (slowly mouths “what ever”)

PM: You’re right that I wasn’t paying attention. There’s too much going on to think I can keep every important detail in my head. How often would I have to make updates?

Project log: Think of your project like a story—make an entry whenever something happens to move the plot forward. Deployment problems on the QA server? There are potential ramifications here—make an entry. Organizing a call time with the client? You probably don’t need to document the detailed back-and-forth in the log.

PM: Ok, I’d like to try this as an experiment for a couple of months. I’m not sure how this is going to work out, or if it’ll be too much overhead, but it’s worth a shot. Welcome aboard, Project Log.

Burnout and the Clean Slate

Tue, 05 Sep 2017 00:00:00 -0700

I manage between 15-20 digital projects at any given time. A few months ago, the constant onslaught of follow-ups, checkins, updates, expectations, and negotiations was taking a toll. No matter how much I slept I was always exhausted—stress wouldn’t let me rest. I was always thinking about work, but my performance was suffering and the quality of my home life was sinking. I was burnt out.

It would have been easy to just think of myself as an exceptionally busy person and blame the nature of the work (or anything other than myself). But I was convinced the problem wasn’t how much there was to do, but how I was getting my work done. To assume that I wasn’t at least partially responsible for the impact work was having on my mental well-being would have also meant to assume that my workflow was perfect—that how I chose to manage my day-to-day obligations couldn’t be improved upon.

Friday Night Lists

Things came to a head one Friday night when I found myself with an unexpected pocket of quiet time to myself at home. Instead of firing up Netflix, my first thought was to update some project timelines that I hadn’t had time for during the week. That got me thinking about all of my other incomplete tasks, and how those tasks were going to impact everything I had to do in the coming week. My throat started to tighten.

I had two options: either power through yet another week and find myself back to where I started, or do something to dig myself out of the situation. So I did what I always do when I’ve reached a breaking point—I made a list.

I wrote down everything I spend time on at work: recurring meetings, recurring tasks, the boilerplate project start-up/wind-down processes, balancing project schedules, email triage. I included the tools I use and how they intersect. I looked at how I managed my tasks.

And there it was.

It’s Full of Stars

Taking a step back and looking at how I managed my tasks from a broader perspective, I felt a kinship with those bewildered monkeys from 2001: A Space Odyssey gathered at the base of the monolith. I was in awe.

Over time, in piecing together an efficient system for managing my tasks, I had unwittingly created a higher-order intelligence that had manipulated me into serving its needs rather than supporting mine. For every task there was an associated set of meta tasks—adding, editing, scheduling, labeling, prioritizing, sorting—each adding weight to the load. If I wanted to reduce how much stress I was under, the first step was to reduce the weight of each task.

It’s Not You, It’s Me

Like ending any bad relationship, you have to accept that change is scary and you have to be willing to commit to your decision. For me, this meant giving up on a workflow and tool that I had been in love with for years. I’ll always have a soft spot for Trello, and I continue to use it every day in other capacities. But for managing large numbers of small tasks, it was far too heavy.

The help I was seeking came from a dedicated task manager. Todoist is working pretty well so far—it’s giving me the lightweight, scalable approach I was in such desperate need of. But it was my commitment to a few simple rules that helped restore my mental well-being:

Every task has a deadline.
Every day has a small, achievable set of non-negotiable priorities that are completed before everything else (I’m looking at you, email and Slack).
Every day ends with an empty list. If time runs out, reschedule the incomplete tasks.

This last rule has helped me the most. Seeing an empty list at the end of every day has had a profound impact on how I see my work life. I don’t take work home with me any more, I’m far less stressed out, and I finish the day with a sense of accomplishment, rather than dread.

Sure, I have more work to do than I’ll ever hope to complete. But for today, my list is empty.

That Time I Learned About Managing Expectations

Wed, 26 Jul 2017 00:00:00 -0700

I remember the exact moment I learned the importance of managing expectations in project management. It happened eleven years ago this month, I was managing a research outpost in the Canadian Arctic, and I wasn’t wearing enough layers at the time.

I was working in Resolute Bay, the second most northerly community in Canada (population: 230, and a logistics hub for Arctic research). The rest of my team was based on an uninhabited island accessible only by air, 165km away (almost the distance between Vancouver and Seattle). Among other things, I was responsible for coordinating the transportation of about one hundred people and thousands of pounds of cargo to and from the Arctic, and to and from the island.

As in any project, communication was key. The tools at my disposal: a crackly pay phone for calling South and a satellite phone with a spotty connection to the island. This was 2006, so pocket computers weren’t a thing yet. The Canadian Far North didn’t (and doesn’t) have a mobile network, anyway.

Ch-Ch-Changes

One night, two members of the research team arrived in Resolute from Ottawa. As we talked about their departure for the island, which was scheduled for the following morning, a new plan started to come together. Scheduling delays earlier in the day meant there were still a couple of cargo flights due to leave for the island later that night. It would take some re-shuffling, but I could get the researchers on one of those flights and save them the cost of a night’s hotel stay in Resolute, which would also help them hit the ground running with their fieldwork the following morning.

The Arctic is a place where plans need to be flexible but well thought out—the weather changes constantly, medical support is generally very far away, and: polar bears. Patience and forethought are critical for project managers in the North, so I thought through the new plan:

Camp population at that point was still well below the maximum allowable.
It was after dinner at camp but the researchers had already eaten during their flight North. Our cook would be able to accommodate two extra breakfasts without having to re-work the meal plan.
Bumping a couple of fuel drums off the flight to make room for the researchers and their gear wouldn’t be a problem—even if weather closed in, camp had enough fuel for a couple of weeks.

The idea was safe, pragmatic, and would save the team money. At this point all I needed to do was communicate the plan to camp during our scheduled evening sat phone check-in.

Ground Control to Major Tom

Anger sounds a lot like static on a bad sat phone connection, but you can generally tell the difference by the amount of swearing.

Despite many attempts, I wasn’t able to connect with my team to relay the change in plans until after the two researchers arrived on the island. Sending passengers to or from the island unannounced was against protocol, and something that I had forgot. It didn’t matter that the plan was sound. What mattered was the team wasn’t given the opportunity to run through the same thought process that I had in order to vet the idea and arrive at similar conclusions. Instead, when put on the spot, my boss arrived at different conclusions, some of which, apparently, were anger-inducing.

I stayed outside on the gravel airstrip for a long while after my boss hung up, taking in the cold and silence. It was late and no one was around. I felt awful, and with my friends and family over three thousand kilometres away, I had never felt so alone. I could have used a thicker pair of socks, too.

I wish I could say that I haven’t mishandled expectations on a project since then, but I have. Managing expectations is hard—whether deploying people or code, it requires pragmatism, creativity, empathy, and a thorough understanding of the rules. Perhaps more importantly, it requires reliable and regular communication with the right people at the right time.

Further requirements such as “the internet” may be project specific.

Beyond Project Management

Sun, 25 Jun 2017 00:00:00 -0700

I’ve come to understand that projects contain dark matter—unseen stuff that exerts a force on the things you can see (plans, budgets, and people), but is otherwise not directly observable. If you’ve ever thought to yourself: “We all saw that deadline coming at us like it was moving in slow-motion, so why did we miss it?”, “How come the client has a different definition of ‘done’ than the one we all agreed to?”, or “Our project roster hasn’t changed, so why is Project B suddenly being prioritized over Project A?”, then you’ve experienced dark matter’s influence. In hindsight, it’s easy to fire off a bullet-point explanation covering all the bases of what we swear we won’t do next time. But beneath the surface, why are projects constantly being nudged toward failure?

I’ve also come to believe this dark matter has fuelled my occasional bouts with Impostor Syndrome—it drives the sense that something is going on just beyond my comprehension, that I should already know what to do about it, and that I’m ill-equipped to manage the situation. My project management education definitely has gaps, so I thought that addressing these weak spots might help me to better understand dark matter and continue to grow as a PM.

Unknown unknowns

I started my search by looking into certification programs. We recently did a two-day course at my workplace on Agile methodologies and how to apply them, so becoming a certified professional Scrum master seemed like it might be a good fit. I also looked into working toward my Project Management Professional certification, with the hope of getting a better understanding of well-worn best practices. But I think both approaches would have left me somewhat unfulfilled. I already knew what I didn’t know—I was itching to find out what I didn’t know I didn’t know. I needed a less traditional approach to get me moving in the right direction.

I decided to sign up for Beyond Project Management—a one-day course offered by Pyxis Technologies in Vancouver. I wasn’t sure what to expect since the course outline and related materials included things I had either never heard of before or didn’t typically associate with project management—the power of intention, Integral Theory, Zig Ziglar. But if I was going to learn more about dark matter, looking... beyond project management sounded like a good place to start.

Over the course of the day, the facilitators guided the class of seven participants through a series of exercises and discussions. I was surprised at how skillfully they created a comfortable space that made it easy for people to share personal challenges. By the end of the day, two central themes started to emerge for me:

People are hard.
Working on tasks isn’t the same thing as working with intent.

Meaningful specifics vs wandering generalities

We can never really know what drives another person to do the things they do. In fact, they might not even truly understand their own motivations—their personal dark matter. But for the purposes of coordinating a group of people, it’s possible to create a more inclusive, engaging, and ultimately more successful process simply by paying attention to your teammates. Who are the introverts? The extroverts? Who’s reacting to why they’re doing certain work? Who’s orienting toward what the tasks are or how the work will be carried out? We don’t need to see this dark matter, but if we’re aware of its presence and sensitive to how it exerts its influence, we can accommodate it.

Turning inward, how much of what we do is driven by clear intent versus a desire to make sure every to-do gets done? As project managers, we take care of people, and often that means doing whatever it takes. But sometimes our interventions can be too much of a good thing, and other areas suffer. How many of our daily tasks can be tied to a specific goal? Is every step of our various processes in direct service to a specific and meaningful intent? Hazy to-do lists and an unquestioning reliance on process are indications of dark matter. A clear intent cuts a straight line through the fog toward what’s most important.

Next steps

In terms of specifics, here are the top 3 things I’m trying to focus on since completing the course:

Be intention-driven rather than task-driven. Map out clear, overarching intentions and let those dictate my priorities, rather than Slack or email.
Be more people-driven than process-driven. Re-examine processes to cut out anything that isn’t tied to a clear intent, and give the introverts (like me) the time and space they need to prepare for meetings.
Breathe. None of the above is going to be helpful if I’m stressed out. A quick breathing exercise helps to expand awareness from the small scale of the issue at hand out to the big picture, where meaningful solutions can be found.

I won’t pretend that a one-day course has prepared me completely for the challenges of navigating dark matter when managing projects. But I’m now much more aware of how to look for it, and I’m equipped with some basic techniques for what to do when I feel that little nudge toward failure.

The Out-of-Scope Request and Mr. Spock

Tue, 08 Nov 2016 00:00:00 -0800

Generally, a client’s out-of-scope request seems ridiculous because, as a project manager, you see these requests for what they often are—an attempt to get something for nothing. But clients don’t see things through your eyes, and PMs often don’t take the time to understand where the client is coming from, either—clients generally care a lot about their project and they’ve paid money (maybe a lot, for them) for you to solve a problem. They just want things to turn out right.

Or, maybe they’re an asshole.

Regardless, an out-of-scope request is a potentially volatile situation that’s wrapped in a thick layer of emotion and mis-matched expectations. But instead of seeing this as a conflict to avoid, or an argument to win, what you’ve really been presented with is an opportunity to strengthen the relationship with your client. Easier said than done.

What to feel when you’re feeling feelings

Once you have what you suspect is an out-of-scope request in writing and you’ve talked the situation over with your team, it’s time to put some careful consideration into your response. But it’s hard to strike a constructive tone and keep your cool when you’re essentially having to convert an illogical request into a logical course of action.

When I’m in this situation, to cut through all the non-essential stuff that I feel and get to the stuff that I know, I pretend I’m writing to Spock from Star Trek. Spock may be the polar opposite of the client I’m working with, but I operate on the assumption that most generally reasonable people have a hard time rejecting reason. Even if that assumption is false, since this response will be the first volley in what has the potential to become a heated discussion, I don’t want to start things off by pouring gasoline on what might turn into a fire.

How do you win over a Vulcan? By being clear, concise, patient, firm, and sensible. Spock doesn’t care about the project’s emotional baggage or extenuating circumstances. He doesn’t care about the timing of the request, how that unexpected bug is already threatening the schedule, or how hard everyone’s been working on the project. Spock cares about a logical argument based on facts and coming to an equitable solution.

If I can’t hear Leonard Nimoy’s voice when reading over my response, I rewrite. I don’t hit ‘send’ until I’m confident I’ve built a succinct, logical argument supporting my view that the request is out of scope, and suggesting an alternative course of action to keep the process moving forward.

Are you out of your Vulcan mind?

The one thing your client won’t do upon reading your response is congratulate you on your astute use of logic in diffusing a particularly sticky situation. More likely, they’ll be shocked and maybe even angry that you’re pushing back on their request. But the response wasn’t the end of the process, it was the beginning.

A well thought-out response gives both you and the client an opportunity to find that point in the past where you both shared a common understanding, and identify where that understanding started to diverge. This shouldn’t be about about who’s right and who’s wrong, or about backing down versus drawing a line in the sand. It’s about working together, respectfully.

"May I say that I have not thoroughly enjoyed serving with humans? I find their illogic and foolish emotions a constant irritant."

—Spock, “Day of the Dove”

Projects would be easy to manage if it wasn’t for all the humans.

Process Creep

Wed, 28 Sep 2016 00:00:00 -0700

As a Project Manager, it’s not uncommon to find yourself questioning the very nature of existence from time to time. Anyone who’s ever managed a project has probably had a client interaction that made them feel like the spacetime continuum had folded in on itself. But I find it even more disorienting when reality starts to break down within my team. Here’s an example:

You and your team have a well-defined routine. You’re all onboard with it. Week after week the routine is working great—if we do this, we get that. It’s something everyone can rely on. But then you find out one or more of your teammates are following some weird, parallel-universe version of the routine and it’s not producing the desired outcome. The change seems sudden and forces you to question what, before this, had been a pillar of consistency.

How were things working so well up until now if the routine wasn’t being followed? Has anyone else deviated from the routine? Where did this Bizarro routine come from? Why are my teammates surprised that I’m surprised about this?

Welcome to Process Creep.

Death by a thousand cuts

Like scope creep, the glue that keeps your projects together is also susceptible to incremental, almost imperceptible, changes over time. At first these alterations don’t seem to matter and may even be encouraged depending on your work environment—if the end results are the same, it might not matter how people adapt the routine to fit their workflow. Over time however, these casual changes can add up to have large-scale implications.

Addressing Process Creep isn’t about making sure things are done your way, it’s about safeguarding the things that make you and your team successful. Here are some warning signs to watch out for:

A lack of formalization. There’s a difference between a routine and a process. I think of a routine as an informal rule of thumb, and a process as something that’s formal, documented, and reviewed periodically. If you suspect you’re seeing Process Creep, it might mean that your routine isn’t as well-defined as you think.
Over-complication. Having a well-defined process isn’t all that useful if it’s overly complicated. Your team may be having a hard time remembering the steps or knowing how to make decisions along the way. For most small to medium-sized projects, the best processes are the ones that feel organic.
Iteration and restlessness. The way I manage my to-dos today isn’t exactly the same as how I managed them a year ago. These changes are based on a perceived need for refinement, but also on restlessness. Sometimes, despite common sense, we have a tendency to change things just for the sake of of change. For personal processes this might not matter much. But when a process involves more than one person, subtle changes often have wider, unintended consequences.

Put yourself in their shoes

It’s easy to get frustrated by Process Creep. There’s a tremendous amount of comfort in thinking that you and your teammates are all on the same page when it comes to how you get work done. When you discover a disconnect, it can be pretty jarring.

But try to keep in mind that, as a manager, process is your job and making things is theirs. So schedule a check-up of your processes every once in a while. After all, you’re supposed to be thinking about this stuff so your team doesn’t have to.