Video Synopsis Of This Article
Project Management for Today is pleased to offer a short Video Synopsis of our articles. This video will share the article highlights with you in a quick fashion.
Let’s you and I agree right up front to dispense with the fluffy 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 kickoff, 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 off 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 spiffing up your LinkedIn profile. 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.
Outlaw 1: You don’t have a way to visualize the work.
Every project has a flow 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 flow, and there’s a very good chance you’re sitting on top of a traffic 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.
Grab a white board and some tape or pull up Trello and make columns. The first column is labeled “To Do” at the top. This is stuff 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 stuff 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 first problem at this phase: you have an obvious bottleneck (usually with your most technical folks [see Outlaw 4, below]).
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.
Are there ways to avoid this situation in the future? Absolutely, but that will need to wait for another article.
Outlaw 3: You’re making bad internal handoffs
So, let’s go back to the board. In between each column is usually a handoff point. Quite often, this is between two different resources (e.g., between a business analyst and a developer). My money says these handoffs 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.
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 handoff 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.
Outlaw 4: You’re bad multitasking your key people to death
This is so common and is also a huge, huge killer of projects. Chances are, new work appears and flows immediately downstream to your developer or emergency room doctor or whomever is the most technical, highly-trained person in the flow. 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 figure it out.
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 fix 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 flow 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, buffer, roap” and “the five 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 off completely oblivious to the other 15 number one priorities others have dropped off. 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.
Peel back the onion on these four items, start fixing stuff, 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 first because I’ve found them to be the root cause of the majority of project issues.
Enough said. Let’s get to it. And don’t leave me hanging—I’m here to help.
Download this article in PDF Form – CLICK HERE
Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.
|Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE|
|We hope you will consider joining our Facebook Community as well. Click on the image to your left to visit and join, or you can CLICK HERE|
Reading this article qualifies you to submit a request for PDU’s from PMI.
This Article qualifies as follows:
PDU AMOUNT: .25 PDU’s
For more information on registering your PDU’s with PMI – CLICK HERE
At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!
If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.
This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE
Randy received his undergraduate degree in Business, Corporate Communication, and Applied Information Technology from the University of Baltimore, and his MS in Information and Telecommunication Systems from Johns Hopkins University. He also has five professional certifications: PMP, PMI-ACP, CSM, SAFe, ITIL along with a certificate in Finance and Accounting from the University of Utah.
He’s worked as a business analyst, senior business analyst, IT project manager, IT program manager, and now as a senior IT project portfolio manager for a variety of organizations that include mom-and-pop companies as well as such household names as T. Rowe Price and The Washington Redskins.
Randy has a particular interest in the nexus of Agile and the Theory of Constraints, and consults on a limited basis with select clients through Epiphany Associates, LLC. Randy is the founder of the Projects and Systems Podcast
Projects and Systems Podcast - hosted by Randy Cox - CLICK HERE