The First Four

Things I Check
When a Project is in
Trouble

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Let’s you and I agree right up front to dispense with the u y opening three
or four introductory paragraphs (that we all skim over anyway) and just get
right to it, shall we?

You have a project going sideways.  It’s yours.  You own it.  It’s your baby. 

You lined up a talented team, appointed a project manager, signed the

charter, gave the project your full support at the kicko , received weekly
status updates, and now the you-know-what is about to hit the fan and that
is no-freakin-bueño for your organization, and especially not for your
career.  You’re sweating.  If there was a 9-1-1 for projects, you’d be dialing it
right now instead of reading this, because truth be told, deep down, just
between you and me, you don’t have the foggiest idea why this has gone o
the rails or what to do about it, do you?  

Straight up?  If you screw this up, bye-bye to the promotion.  Sayonara to
the C-suite.  No bonus.  You’re going be the guy or gal who couldn’t
produce, messed this up, and you might as well climb into a glass box right
now and get comfy or start spi ng up your LinkedIn pro le.  You haven’t
been this scared in your professional life for a long, long time. 

Alright.  We understand each other.  Enough of that.  What do you need to

do about it?

Clear your schedule and dive into the following four areas.  Like, today. 
And because I enjoy an occasional western (and listening to Willie and
Waylon), let’s call these the four outlaws.

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Outlaw 1: You don't have a way to visualize the work

Every project has a ow of work.  In IT, it might be analysis of business

requirements before you ask a developer to start coding, which comes before
quality assurance testing, which precedes the whole build and release
process.  In construction, you have to lay the foundation before you frame,
so you can wire and plumb, before you get the roof on.  You get it.  Your
project has a natural ow, and there’s a very good chance you’re sitting on
top of a tra c jam that you can’t see.  You need to make the work visible. 

The best way I know to do this is through a Work in Process (WIP –

pronounced “whip”) board (Kanban for the Lean purists out there).  It’s the
same thing. 

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Grab a white board and some tape or pull up Trello and make columns. 
The rst column is labeled “To Do” at the top.  This is stu you need to do
but have not started yet.  If you’re an Agile purist, call it “Backlog.”  I really
don’t care. 

The next several columns will be Work in Process (WIP).  This is stu you’re
actively working on right now.  Under the “WIP” Heading, make a column
for each additional step in your process (e.g., Analysis > Design >
Development > etc.).  Keep going until you arrive at the last column which
is labeled “Done.” 

Is there more to this?  Heck yeah.  I do a four-hour seminar on this, but this
will get you going.  Build the board, rip open a stack of index cards, grab
some Sharpies, and create one card for each piece of work traveling through
your system.  Then, place each card on the board where it currently sits.  

It’s not uncommon to take a quick step back and see your rst problem at
this phase: you have an obvious bottleneck (usually with your most
technical folks [see Outlaw 4, below]).

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Outlaw 2: You have external dependencies in your

schedule that you either didn't account for, didn't
fully prepare, or didn't adequately buffer

External dependencies (XD’s) are killers.  This is when your work has to
travel outside of your team to some other team or group or company that
you don’t control.  More than likely, they don’t agree to or care about your
prioritization system, and what might be red hot for you might be a yawn
for them.  The work is on their turf now.

At this stage, you need to get on the phone (or a plane) and start explaining
the situation, apologizing, and negotiating on how to move things along.

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Are there ways to avoid this situation in the future?   Absolutely, but that
will need to wait for another eBook.

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Outlaw 3: You're making bad internal handoffs

So, let’s go back to the board.  In between each column is usually a hando
point.  Quite often, this is between two di erent resources (e.g., between a
business analyst and a developer).  My money says these hando s are going
poorly and being handled far too casually.  What you want is an Olympic
relay race.  What you probably have is an upstream resource throwing
her/his incomplete work over the wall to an unsuspecting downstream
resource and walking away while the receiving person is now being sent on a
goose chase or scavenger hunt.  All avoidable with a Theory of Constraints
concept called “full kitting,” but a full explanation of that will also have to
wait.   

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

For now, ask the downstream resource to create a checklist of everything she
would need to do her job.  Like it’s all there in a “kit” and all she has to do is
open it and get to work.  No questions.  No chasing people down.  It’s all
there. 

Then, give this checklist to the upstream resource and say their hando isn’t
done until 1) they’ve prepared everything on the checklist and given it to the
downstream resource; and 2) the downstream resource looks it over and says
she’s good-to-go. 

Is there more to this concept?  Same thing.  You betcha.  But we need to
move on. 

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Outlaw 4: You're bad multitasking your people to

death
This is so common and is also a huge, huge killer of projects.  Chances are,
new work appears and ows immediately downstream to your developer or
emergency room doctor or whomever is the most technical, highly-trained
person in the ow.  There’s no attempt to hold anything back to try and
match their capacity.  You just keep the conveyor belt coming like ‘I Love
Lucy’ in the chocolate factory and expect them to gure it out. 

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Well guess what?  They only have so much capacity.  And when you double
or triple book them (or worse), what do they do?  They probably work
overtime.  They probably start looking for another job.  And they start
multitasking.  Bad, bad, bad for productivity.  You might as well throw in
the towel right there if you want to keep doing this because this bad practice
will absolutely kill progress. 

I have lots more to say about this, but we don’t have time.  You need to x
this.  Go to the board.  Stop anything else from going to your
bottleneck/critical constraint.  Put a dam in front of their column and don’t
let any more work spill over it until their column is clear.

Let the resource “go dark” and not attend any meetings, be on any status
calls, and just put their head down and work on their column.  When it’s
cleared, then slowly start letting prioritized, full-kitted work ow to the
resource at the pace they can handle it (and no faster).  You will need to
recalibrate the upstream and downstream resources to march this new drum
beat.  This is simply applying another powerful TOC concept called “drum,
bu er, roap” and “the ve focusing steps,” but don’t worry about those
details right now.  Stop multitasking your key resources!

I will bet you there are multiple team leads, customers, bosses, all dropping
super high-priority work on this resource’s desk and walking o completely
oblivious to the other 15 number one priorities others have dropped o . 
Why?  Because it’s invisible (see Outlaw #1).  Stop it.  Get it all on the board
and have one door the work goes through to these folks with a big, bad
bouncer.  

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Summary

Peel back the onion on these four items, start xing stu , and then let me
know via your comments below or through a private LinkedIn message how
it’s working.  We may need to go into a bit deeper dive the next time
around. 

Are there other things out there lurking in the shadows that can derail your
project?  I’ll pretend you didn’t ask that.  Of course.  Lots of them.  But
these four outlaws are what I always check rst because I’ve found them to
be the root cause of the majority of project issues.

Enough said.  Let’s get to it.  

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL

 The First Four Things I Check When a Project is in Trouble

Come join me on the Projects and Systems Podcast for brief, useful episodes
on the big, Venn diagram that is project management, process improvement,
and time management.  

10 minutes listening on your way to work, will save you hours or days when
you get to to work!

You can nd us on SoundCloud, iTunes, and Stitcher.

And please connect with me in LinkedIn!

Randy Cox, MS-ITS, PMP, PMI-ACP, CSM, SAFe, ITIL