Notes from Digital PM Summit 2016

I’m the I was the closing speaker today yesterday at Digital PM Summit in San Antonio, TX, and I’ll be taking notes (or in fancy terms, liveblogging) for every session that I sit in until it’s my turn. I’ll be following the basic rules of Min/Max note taking and will update this post as the day goes on. It’s the first PM event I’ve been to in years – brings back many memories from my first career.

Brett, one of the organizers of PM Summit, asked the audience how many people became Project Managers / Producers on purpose, vs. how many fell into it accidentally, and most of the room raised their hands as accidental! (He joked with a slide that said “You are not an accident” :) This isn’t a surprise as often the role evolves as a project or organization gets larger.

It’s also a related observation that most people don’t know what a project manager does, particularly digital project managers. Once during a trip he was stopped by a UK immigration officer who seemed baffled by his job title and asked: “what kind of projects do you manage then?” He shared a list of quotes from colleages who he asked to explain what he did for a living:

“As far as I can tell project managers do nothing, but if they stopped I’m pretty sure everything would fall apart” – Paul Boag

“You help teas organize their work” – Brett’s Mom

“Project management is like sweeping up after the elephants, only less glamorous” – @zeldman #dpm2016

He shared how the History of Project Management goes back at least 4000 years, and that there’s a long history of teams of people making difficult things. But that digital project managers have yet to be entered into that history in a meaningful way, and part of what he’d like to see is greater recognition for the contributions digital project managers make.

7 DPM (Digital Project Manager) Principles: The balance of his talk was an exploration of 7 principles about leading teams and projects.

Chaos Junkies – we thrive on problems because we know we can solve them. We break processes to make new ones. We make our own templates. We managed with our minds, not our tools.

Multilingual communicators – listen and take cues from our team and clients.

Loveable hardasses – reputation for being firm but wise and well intentioned.

Consumate learners and teachers – that teaching teammates helps the project, the organization and the pm

Laser focused

Honest Always – cultivate a reputation for straight talk

Pathfinders – do more than take care of budget and timeline

His final question for the audience was: where will you take us? Which principles resonate the most?

The core of her talk was about the concept of MVP, or Minimum Viable Product, and how to apply it to projects. She referenced Eric Reis’ book, The Lean Startup, and asked who had read the book: I was surprised how few hands went up. Perhaps I’ve been to too many start up events the last few years. I had a hard time following the thread of her talk – she referenced many models and frameworks but it was tough to find salience to pm situations, or connections to each other.

She offered four goals or objectives:

Building just enough to learn

Learning not optimizing

Find a plan that works before running out of resources

Provide enough value to justify charging

She mentioned loop models, were you have a cycle of behaviors you repeat, such as: Think -> Make -> Check. Briefly she touched on Lean UX, and how customers must be involved as part of that check process – “Customers don’t care about your solution, they care about their problem”.

Next she talked about metrics, and offered this quote: “A startup can only focus on one metric and ignore everything else” – Noah Kagan. I didn’t agree with this, as it sounded more more like hyperbole than sanity – plenty of successful startups have focused on multiple metrics, or at least prioritized them.

She offered “Pirate” metrics as good choices for what the primary metric should be:

Acquisition

Activation

Retention

Revenue

Referral

Regarding building software, she explained the Build Model:

There are 3 desirable criteria, but you rarely can do all three

Build right thing

Build it fast

Build thing right

(reminds me of the PM Triangle – “you can have fast, cheap or good: pick two”)

Which she compared to the Learning Model (Learning, Speed, Focus), but I didn’t quite understand how they related to each other.

Lastly she provided this outline, in reference to a project she managed:

She explained that her background is different than most of the audience, but that the importance of feedback is shared: feedback should make it easier for (clinicians) to do their job.

A common mistake in getting feedback is asking for it only when it’s too late, AFTER, the customer has experienced what you made for them. She gave the example of how a waiter at a good restaurant will check in on how you are doing DURING the meal, creating the possibility for them to fix a problem before it’s too late. But projects rarely do this. All feedback is too late.

A goal she has used is to make it possible.. “For all our customers to continually rate the services we provide as good, very good or excellent” and that part of this should be that the customer defines what good looks like (which is important since it forces you to confirm your assumptions about what customers actually want are valid)

Tip #1: Measure what’s important to the customer

Tip #2: Track your scores to show your impact

Tip #3: Make feedback little and often

Tip #4: Don’t expect credit for hygiene factors (things people expect you to do anyway)

Tip #5: Satisfied Customers Make Good Allies

Steps:

Get buy-in – does your team support idea of continuous customer feedback?

Set & Spread the vision – “want majority of customers to score us good, very good or excellent”

Decide who the customer is – it’s often not the most senior or visible person (and segment the customer pool if needed).

Define your scoring mechanism

Organize for success

Align your partners

Launch

Do the work (she joked at once getting the feedback “having a change management process is onerous, so… we shouldn’t have one”)

She closed with the following quote, pointing out how we call use the right words, but the impact is only felt through our behavior.

The number one thing that will screw up a project: people. Feature and scope creep only happens because someone is not communicating well with others.

Projects are complex for many reasons:

How departments are defined

Internal politics

External politics (client)

Team distribution by location

The understanding of the role of designers

Limited budget lofty goals

The most important thing is to avoid being blindsided. If you see problems coming you can prepare, but if you are surprised by something you did not anticipate the damage will be far worse. Almost every problem can be traced back to communication issues and how people relate to each other.

When you take responsibility for your mistakes, other teams will respond in kind.

Admit when you don’t have an answer. There is no shame in not knowing something and it’s far better to put that ignorance out in the open where it can be resolved, rather than hidden (where it will fester)

“I design how my team designs” (as lead)

Work to understand root causes of difficult situations.

Be prepared to ditch your process if it’s not working. It’s the ends that matter not the means.

‘Everyone has a plan until they get punched in the face’ – Mike Tyson

You don’t want to be inventing a new plan when you are in the middle of chaos. Have a backup plan. And a backup plan for your backup plan.

The needed solution might not be the ideal solution. There is what’s ideal and there is what’s real.

First time she worked on a large project she was excited to see a budget so big. The project was to make a video game to teach accounting to high school students. But then she realized her team was small and the expectations the client had were demanding. This led to a kind of crisis: Why me? Why did I want to be in this situation? (In the end they did finish the project on time, but over budget). Over many projects she’s found good answers to this question.

PM is untangling the most complex project and making it tangible.

Essential skills for managing (complex) projects

Adaption

Collaboration

Communication

Expertise

Leadership – cheerleader and bulldozer at same time. Takes time and practice to learn.

Continuously clarify your goals. Goals change and you have to make sure that you are verifying they’ve stayed the same (and reminded your client of them).

Create more visibility – last thing you want is a team member who is working on something that isn’t needed anymore. She explained process maps – a visual outline for all of the roles people need to play, at the firm and at the client. They’d have the client review them, on a huge sheet of paper, answering questions and clarifying.

Be flexible and willing to adapt – As PMs it’s natural to tend to want to control everything, but flexibility (bend not break) can be a strength not a weakness.

Pay attention to the calm before the storm – complex projects are like dating. When you start a project, everyone is excited. But soon interest fades, and slowly problems arise, often creeping up on you and easy to overlook.

Scope Creep causes

Every time you say yes to one more edit, you’re inviting the next one. You must get comfortable saying no, not always but often.

Interference from the client

Incomplete scope

Poor change control

Miscommunication

Effort Creep causes

Overly optimistic estimates

Doing more work without added scope

Lack of skills – “pleasure of working with” a junior person

Hope Creep

Team falsely reports they are on track, which you report to client

Hardest to identify

Hides until the last moment

As much fear as PMs have, designers and developers have it too, but for different reasons

Have a “NO SURPRISE” rule – it’s a two way pact to make sure you don’t set up the other person for failure

Feature Creep causes

Also known as gold-plating

Over-delivery on the scope

adding unnecessary features

“The single biggest problem in communication is the illusion that it has taken place” – George Bernard Shaw

Swoop and Poop

Someone powerful flies in, late in the project, and dumps all over it

You can avoid this by having a list of stakeholders who have the authority to change things late (no surprises)

Our brains are not as impressive as we think they are. We are not designed to handle the amount of information and the cognitive tasks we ask. It’s like taking the first computer you ever owned and trying to use it today to use web.

“It’s not information overload, it’s filter failure” – Clay Shirky

“My wife probably tells me that I never listen” – Rodney Lacroix

He showed an example of awareness bias (watch this video and try to count how many times the white team passes the ball). It’s easy to miss something you’re not looking for. As a side note, ADHD means it’s hard to focus on one thing. While someone with ADHD are more likely to see everything (in the video), but also more likely to get the count wrong.

Layering: two relatively simply things using different parts of the brain (singing while driving, one is physical one is mental).

However two mental tasks at same time: does not work well. Instead of doing them at the same time our brain switches back and forth (fast enough so we feel like we’re doing both, but we’re not).

“Multitasking is the ability to screw up everything simultaneously” -Jeremy Clarkson

He asked the room how many projects they manage at the same time: majority of the room was 6 or more.

General stats (reference?) on performance loss when trying to multitask:

2x as long to finish a single task

50% more errors

40% drop in productivity

willpower drops

decision fatigue

He referenced a study of judges and how they granted parole 65% early in the day and drops until lunchtime, when it returns to a high level.

He was going to talk about procrastination, but then decided to get to it later.

Rest – 7 hours of sleep (Most people who think they need less are probably wrong). Taking breaks is good for body and brain (see pomodoro technique).

Eat – don’t eat bad things.

Move – We work in a chair for 8 hours a day. We need blood flow, to stretch or joints, and our brain is part of our bodies after all.

Plan – Avoid back to back meetings. Try for single tasking – where you are focused on one project at a time.

He gave an example of the conjunction fallacy – is Linda more likely to be a banker, or a feminist bank teller:

“Linda is 31 years old, single, outspoken, and very bright. She majored in philosophy. As a student, she was deeply concerned with issues of discrimination and social justice, and also participated in anti-nuclear demonstrations. Linda is a bank teller and is active in the feminist movement.”

He referenced killer clowns as an example of availability bias, a mental shortcut that relies on immediate examples that come to mind, and also probability neglect.

For PMs an important one is ambiguity aversion – where we will take a known thing, even if it doesn’t work well, over an unknown (known risk over unknown risks).

Another one is illusion of control – dice games where people believe they have an influence over the roll. Or when people yell at their televisions while watching sporting events, or even pushing the elevator button more than once.

Estimation is prone to many kinds of bias (the planning bias documents our tendency, even experts, to underestimate time, costs and more). We also suffer from anchoring bias – whatever first number we hear changes the answers we tend to consider (a factor in speed limits and prices). As a tip, whoever anchors a discussion can likely influence it.

Hofstadter’s law: it always take longer than you expect, even when take into account Hofstadter’s law.

Advice

We are wired with these limitations and it’s not entirely clear how consistently we can overcome them. But there are tactics that minimize their impact and frequency:

Be Sad – our mood impacts our judgement. When happy we are overly optimistic. Consider watching a sad movie before doing tasks were skepticism is required.

Remember – “memory is fiction.. not just a replaying, but a re-writing” Daniel Levitin. Our memories don’t work as well as we think they do – snapshots, not the whole film, and our brain invents to fill in the gaps.