NICK WALKER:  Welcome to Manage This, the podcast by project managers for project managers.  This is our every-other-week meeting to talk about what matters to you as a professional project manager.  Our aim is not just to help you survive, but also help you grow in your talent and your influence.  We talk to those who have been through the wringer and come out on top, people who want to share their successes and their failures with you.

I’m your host, Nick Walker, and with me are two success stories, Andy Crowe and Bill Yates.  And Andy, we welcome back to Manage This a friend and a colleague.

ANDY CROWE:  Yeah, Alan Zucker.  I’m excited he’s back here.  The last time we were talking about Agile specifically, and this time we’re diving into something kind of interesting that’s near and dear to my heart.

NICK WALKER:  Well, for those who don’t know him, Alan Zucker holds numerous certifications.  He’s a certified Project Management Professional, is an ITIL Foundation certificate holder, a Scrum Master, a scale Agilest, and an Agile Certified Practitioner.  He has more than 25 years of experience as a leader in Fortune 100 companies.  He’s delivered thousands of successful projects for them and managed multimillion dollar programs with hundreds of resources.  In 2016 he founded Project Management Essentials to provide training and advisory services.  He is frequently called on as a keynote speaker and is also an adjunct instructor at Northern Virginia Community College.

Alan, welcome back to Manage This.

ALAN ZUCKER:  It’s really a pleasure to be here.

NICK WALKER:  There’s something I believe most of us share, and that is the fact that we’re busy; we’re active; we’re constantly creating something.  But unlike a product that we can hold in our hand, what we create is less tangible.  It’s hard to see.  Kind of reminds me, in contrast, of my first real job.  When I was a teenager I worked in the mailroom of a local community newspaper.  Our product was obvious.  You could see it; feel it; read it.  It rubbed off on you in more ways than one.

But not every paper was fit to send out.  Some of them were smudged.  Some of them were torn, wrinkled.  And at the end of the day we gathered up the waste and tossed it.  Like our product, our waste was easy to identify.  We knew exactly how many papers came off the press, exactly how many we had to throw away.  But how do you measure waste in this intangible world of project management?

ALAN ZUCKER:  You know, it’s really interesting.  There’s a big movement afoot, which is the Lean movement.  You know, when Lean came to us from manufacturing, particularly from Toyota…

ANDY CROWE:  Toyota.

ALAN ZUCKER:  Yeah, Toyota Lean Manufacturing Model.  And when you’re talking about cars, waste is clear.  Waste is inventory.  Waste is transport.  Waste is the scrap that they throw away at the end of the day.  When we’re talking about knowledge work, it’s really harder to see waste and to manage waste.  And a lot of times when people talk about waste in knowledge work they try to use the analogy, say, of manufacturing.  They talk about transport and inventory and scrap, and it really doesn’t carry over that well.

And so when we talk about waste in knowledge work, there’s eight or nine different forms of waste.  And it’s things such as extra features.  It’s work that’s started that’s never finished because you start work; you put forth effort; but until that’s a final product in your boss’s hands – it’s either software that you’ve developed, it’s that presentation, it’s that report – it doesn’t provide any value.

Heroics is another big form of waste, and we see that in a lot of cultures where you’ve got that hero culture, and you’ve got one person that’s the hero, and that’s the go-to person.  And we all love the hero.  In a lot of cultures we love the hero.  But what you’ve got is you’ve got one hero, and you’ve got the rest of the team that’s not working.  Or they’re working, but they’re not the ones that are being engaged, and you don’t have all the minds engaging on the problem.

BILL YATES:  So Alan, just heroics.  That’s a great topic there on waste.  But I don’t get that.  I mean, if I’ve got a top performer on my team, I’m happy.  If I have two, that’s awesome because somebody’s not going to be carrying their weight on my project team.  So I need some heroes; right?

ALAN ZUCKER:  Well, you know, one of my favorite examples, Bill, and you saw it in the class the other day, is when you talk about Toyota, and they talk about the “andon cord.”  And the andon cord is the cord that runs along the Toyota manufacturing line.  And if any worker sees a problem that they can’t resolve quickly, they’re empowered to pull that cord, and it stops the production line, and everybody on that line comes around and swarms the issue, and they help resolve the problem.

And I always ask my students, so how many times do you think people pull that cord?  And they’re like, maybe 10 times a day.  And everybody went no, that’s too many.  Toyota manufacturing plant in Tennessee, they pull that cord thousands of times a day, and everybody comes around and helps resolve the problem.  And so, you know, if you’ve got a situation where the entire team is working together, you’ve got the power of the team.  And I always like to say, you know, I might be smarter than any particular person on my team, but there’s no way that I am smarter than the power of my entire team working together to solve something.

ANDY CROWE:  The wisdom of crowds.

ALAN ZUCKER:  Yeah.

ANDY CROWE:  I go back in time, though.  This is funny.  This idea of heroics comes in a lot because organizations will, a lot of times, get into a situation of perverse incentives.  And here’s where I’m going with that.  You have an outstanding hero on the team, and this is the person – I worked in an organization where this person was key to the organization.  They would get into trouble on a project, and they would send this person in.  He would parachute in, he would code for days, and he would come out with a somewhat working product.  Everybody was in awe of him.  Then he’d take a week off.  They would throw money at him because he would – no.  And now what you’re doing is perpetuating this cycle.

So it’s interesting when you look at this idea of heroics because the hero loved it.  He loved the attention, he loved being indispensable, he loved being the hero, and he loved the extra money.  The organization had built sort of a myth culture around this person.  And ultimately it cost that organization dearly through rework and through mistakes.  It was an ugly situation.

ALAN ZUCKER:  And it also creates a lot of fragility.  It creates fragile code.  It creates fragile knowledge.  One of the interesting things when you look at extreme programming and other pieces of Agile is the idea that the team owns the code; that people don’t own the code individually.  So you’ve got a hero.  He comes in; he saves the day.  There’s the old thing.  He goes off, and he wins the lottery.  Then what happens?  Who can then maintain that code?

ANDY CROWE:  Right.

ALAN ZUCKER:  And the rest of the team gets demotivated in that kind of culture.

ANDY CROWE:  Right.  I bet you’ve never heard the phrase “My code’s self-documenting.”  “I don’t need comments.  My code’s self-commenting.”  Sure it is.  Sure it is.

ALAN ZUCKER:  I always worry when I hear that phrase.

ANDY CROWE:  Well, for good reason.  But again, a hero wants to be indispensable, needs to be indispensable.  And so there’s no incentive to comment his or her code.  Right?

ALAN ZUCKER:  Yeah.

ANDY CROWE:  The incentive – in fact, there’s perverse incentives once again.  And so getting rid of that culture, that’s tricky.  Especially if your organization has it in its DNA.

ALAN ZUCKER:  Yeah, and I don’t know if you…

ANDY CROWE:  A lot of consulting companies do.

BILL YATES:  Mm-hmm.

ALAN ZUCKER:  I think a lot of every kind of company does.  I think it’s really hard to change that culture.  And I think it’s really telling that, whenever I ask my students that question about, you know, how many times a day do they pull the andon cord, I don’t think I’ve ever had anybody that says more than a hundred times.

ANDY CROWE:  Well, I find it astonishing from the standpoint that my workflow as a production employee would be interrupted that often.  That I have a hard time getting my mind around, too.  So I understand their confusion.  It is – I’d like to see it in use and see how practically it works to do it.  But it’s pretty amazing.

ALAN ZUCKER:  Well, one of the other aspects of Lean is fixing problems at the source, and that fixing a problem at the source is much, much cheaper than fixing it later.

ANDY CROWE:  Right.

ALAN ZUCKER:  And there’s a guy named Capers Jones who’s done some phenomenal work on software quality.

ANDY CROWE:  Yeah.

ALAN ZUCKER:  And he talks about the cost of fixing problems further down the line.  And it’s exponential.

ANDY CROWE:  Yes.

ALAN ZUCKER:  And when I talk about it in class, and I use the analogy of Toyota…

ANDY CROWE:  The recall is a great example, sure.

ALAN ZUCKER:  Recall is a great example.  But I also talk about – imagine this.  You’re the guy that’s putting the screws in the door.  You know, you drop the screw into the door.  It falls down.  I need to pull that cord.  I need to probably just take another 30 seconds to reach in, fish that screw out.  It’s a small stop.  Now imagine that door gets to the QA.  So they’ve got to take the door off the car.  They’ve got to take – disassemble it.  They’ve got to pull the screw out.

Imagine it doesn’t get caught there, and a consumer buys that car.  They’ve got their brand new car, they’re driving down the road, and they hear click-click, click-click, click-click every time they go over a bump.  So now the consumer’s got to go back to the dealership, and it’s a whole big production, and it’s also a loss of reputation that I’ve got this rattle in my door.  And if we would have taken another 15 seconds or 30 seconds on the line, we could have fished that screw out, and it wouldn’t have been there.

ANDY CROWE:  So there’s a tremendous practice among, I know Lockheed specifically, and the Air Force also does this, where they are fastidious about checking for foreign object debris (FOD) on runways.  In any production facility, you check your shoes.  You do it meticulously each time.  You check the tire treads.  They have people out on the runway checking anything that’s coming onto the runway.  And the reason is they don’t want you tracking in some pebble that gets down in a grate somewhere and rattles and drives the customer crazy from then on.  They want to deliver a clean product.  I have been to a Toyota manufacturing facility, and it was utterly spotless.  It was shocking how clean it was.  And so this idea, yeah, it gets into it.  I see exactly where you’re going with that.

ALAN ZUCKER:  Yeah.  And there’s a lot of other aspects of – when we talk about Lean, and we talk about waste.  One of the things I love to talk about the most is multitasking.  We all multitask, but none of us really multitask.  We task switch.  And I heard something recently where there’s an estimate that we lose between 20 percent and 40 percent of our productivity when we go from one thing to another.  And that could either be the time it takes to put away one set of work and pick up the next set.  It could be the idea that you need to get your head back into the game.  And when you start talking about that, the effect of multitasking, it becomes really interesting.

So I tell people, you’re a project manager.  You’re working on one project.  You’re spending 40 hours a week working on that project.  You have two projects.  Now you’re spending eight – if you assume 20 hours a week of – I’m sorry, 20 percent of waste from task switching, now you’re losing eight hours to task switching, so you’ve got 32 hours.  So you’re really only working 16 hours on both of the projects.  When you get into three projects, you’re now spending more time task switching than you are on either of your projects, or any of your projects.  And I think that waste and that loss of capacity is huge.

BILL YATES:  Alan, I can relate to that with projects that I was working on back in the day with utilities, and I think of the software implementations that we were doing.  The most effective time we had as a team, we’d have to say, we’d have to admit to it, was when we were onsite at the customer’s location working with their team.  That, you know…

ALAN ZUCKER:  Right.

BILL YATES:  There’s an accountability built in there.

ALAN ZUCKER:  Mm-hmm.

BILL YATES:  I’m not going to be working on, let’s say, Tucson Electric’s power if I’m at Pacific Gas & Electric.  That’s not going to happen, right?

ALAN ZUCKER:  Right.

BILL YATES:  So you’re focused on the client, and you’re – so at least that element of multitasking wasn’t taking place.  Now, within the project work, you know, there’s still times where maybe I need to drive something to completion before I go to that next issue, so there’s a lot of decision-making that goes on there.  But I can absolutely say at a macro level, the most effective work that we would do on project teams is when we were focused, maybe think about a war room, or we were onsite with the customer and really doing that.  So, yeah, I can relate that to real work.

ALAN ZUCKER:  And it can also be on the micro level.  You know, one of the things that I really fight hard to not do is task switch in the middle of doing something.  So what I’ll frequently do is I’ll start something, and I’ll fire up my web browser to find something, and it’s moving slow.  So I just go to my email, and I start looking at my emails.  And then the browser comes up.  And then I’ve got like two emails open.  And even something that small, the time to go back, it’s like what was I going to execute next?

BILL YATES:  Yeah.

ALAN ZUCKER:  If I just would have spent that extra 15 seconds and been patient and waited for the application to load, I would have been better off, rather than starting three other things and then getting half of something done.

ANDY CROWE:  Plus you’ve got that browser open, so you just started shopping for some new hiking boots or, you know.

ALAN ZUCKER:  Yeah, exactly.

ANDY CROWE:  Email to me is a key culprit here, though; and productivity experts talk to us about it all the time.  There was a great Dilbert cartoon where a character asked Wally, “Have you read that email I sent?”  And Wally said, “If I open my email in the morning, then I’m going to have 30 things that dictate new priorities for me.  So no, I haven’t looked at it.”  And she said, “Well, will you get to it tomorrow?”  And he said, “You should try and live in the moment.”

But there’s this idea.  I turn email off a good portion of the day, and we encourage people here in the office to do it, as well.  Not all day, and not every worker can.  Some workers need to be highly responsive, especially to customer issues.  But in general, I need to stay away.  And the most evil thing about it, the most pernicious one, is when the little bubble pops up with a message that’s come in.  You don’t even have to click on it anymore now.  It’s going to get your attention.  And so email is fighting for your attention at every moment, and I cannot stay on task.  I task switch pretty well, maybe better than average.  Maybe not.  I don’t know.  But I task switch pretty quickly.  But you can go down the rabbit hole instantly with email.

ALAN ZUCKER:  Yeah, a really good friend of mine – one of my favorite podcasts is Manager Tools, and Mark Horstman talks about doing email three times a day.  You do it in the morning, you sort of do it mid-afternoon, and you do it at the end of the day.  And I haven’t gotten to that level of discipline.  But I know when I’ve been in the situation where I’m able to put all of the distractions away, I can just chug through things, and I am amazingly efficient.  But when I’ve got the distractions, and I’m looking at what’s coming in, or I’m like, got my browser open, and I’m looking at something else, I can just get lost in doing things.

NICK WALKER:  So we talked about a few areas of waste already, but what other things do we really need to be wary of?

ALAN ZUCKER:  One of the things that I see, particularly when I’m working with IT organizations, is the notion of waste coming from motion, handoffs, and waiting.  And you often see that when you’ve got groups that don’t have end-to-end responsibility, and you’ve got to call in another group, a support group, to do a piece of the work for you.  So you’ve got to a point you need to submit a help ticket; and you’ve got a group that’s going to, like, say, set up your environment for you.  And they’ve got a two- or three-day service-level agreement for them to do that.  So you’ve got there, and you’re waiting for that other group before you can do that step.

Actually, not too long ago I was involved in a project where, as the director, I got pulled in to help this project along.  And it had been a long time since I had actually rolled up my sleeves and gotten my hands dirty.  And the project wasn’t going well, and we would have these daily meetings at 9:00 o’clock.  And I swear to God, it seemed like things got off the rails by 11:00 o’clock, and no one got – no one sort of – we didn’t reconvene again till the next morning.  So we lost basically an entire day till we reconvened, and we got everybody back on the same page.

So we lost, you know, every day we probably lost a half a day’s worth of effort just because we were waiting or because we were waiting from handoffs, from one person to do part of a job till they could hand it off to the other person to do the other part of the job.  And no one had that end-to-end responsibility.  And that’s also another form of waste that we see a lot of in technology.

BILL YATES:  I see the value of flow charting here is just glaring to me.  I’m thinking of TSA wait lines.  I’m thinking of transportation projects that are going on, and seeing resources that are standing and waiting.  I’m like, why are there 10 guys with hardhats on that are waiting on the side of the road?  What’s going on?  Then you see maybe a large crane being moved into position.  So there’s like some real obvious things that I think of.

But it’s so frustrating, even on software development, when there are steps that we’ve done, and it’s almost back to leads and lags, building them into our schedule.  But there’s this – there’s waste going on.  You’ve got people with knowledge that need to be doing something.  Like you said, there needs to be a role, someone above this who’s orchestrating this.  Whose role is that, to make sure we’re eliminating that waste?

ALAN ZUCKER:  One of the things that, you know, the project manager or process owner can do that’s really, really valuable is what we call value stream mapping, you know, and the idea of looking at the value stream, end to end, and looking at what we’re doing, and looking at the things that provide value.  And value’s defined as what provides value to the customers.

BILL YATES:  Right.

ALAN ZUCKER:  You know, what contributes directly to the product?  So some of the things that we do, particularly when we’re doing them in a project, we do reporting.  We do approvals.  We have, you know, lots of meetings.  And a lot of those things are necessary.  I mean, we have some approvals.  We need to have some level of reporting.  But those things don’t add value to the end product.  So we really, really should evaluate what we do and say, is that really necessary?  And some of those controls are necessary, but some of them may not be.  And if you can start stripping some of that out, the flow becomes easier.  We’re actually adding the productive capacity to our days, and we’re able to be more efficient in what we do.

ANDY CROWE:  Alan, I go back – I have a lot of passion for this particular topic, and there are a lot of reasons behind it.  One of them is, I’ve mentioned on the podcast before, I own an event-rental company with my oldest son.  And we rent tents, tables, chairs, staging, dance floors, linens.  But the amount of potential waste in that business is astonishing.  And we’ve gone back and started implementing a Lean system, a Lean-inspired system, to root out the waste.

And in that system, which has so much in common with what you’re talking about – it’s a little, tuned a little bit differently.  But you have really three big categories, the Japanese categories of Muda, Mura, and Muri.  And the Muda is the one that says any activity – this is what you were talking about with value stream mapping – any activity that doesn’t add value gets eliminated.  And so now you become really focused on what people are doing, how they’re doing their job, and making sure that every activity, every motion adds value.

And then the Mura is the waste of unevenness, when you’re crushing and crisis time and then so forth.  I’ve got a friend who owns a company that makes kayaks, and they have a huge problem with unevenness.  Now, he’s doing amazingly well.  He’s having kind of jaw-dropping success with the company.  But one problem he has, he has to rent a warehouse that is absolutely enormous.  It gets full of product, and then within 48 hours that warehouse is empty again, and so he has this ballooning problem, which is kind of Mura.

And then Muri is the overburdening, you know, the soul-crushing, dehumanizing work that we put on people, which can also tie back to this.  And yet it’s so – so there’s a lot of overlap in the two worlds between knowledge workers and sort of the physical world, as well.

ALAN ZUCKER:  And I think the big difference there is it’s really apparent in the physical world.  You know, your friend can see the inventory coming and going in and out of the warehouse.  But it becomes much harder to see that in knowledge work.  You know, it’s really hard to see the work in progress.

ANDY CROWE:  And we call it “crunch time” in the knowledge work.  That’s, you know, we say, “Oh, I’m, you know, head’s down,” things like that.

BILL YATES:  Right.

ALAN ZUCKER:  Yeah, or it’s where we’re focusing on something that, does that really provide value?  So one of the things that was really interesting when I was supporting the accounting group is we went through a value stream analysis, and we looked at how much effort we were spending on the different pieces of the revenue stream versus the effort that we were expending to do that accounting.  And out of a billion-dollar revenue stream, one of the things that we saw is we had an old, small product that we’re maybe billing about $100,000 a month.  But we were spending a lot of time trying to capture the revenue for that.

And what we realized is we could easily just estimate the revenue that month; and then, if there was a variance, we could just true it up the next month.  And any of those differences were really immaterial.  But what we did is we created a lot of capacity for the accountants that were working on that to work on things that were much more important and much more material and much more valuable to the company.

NICK WALKER:  There’s another time waster that sometimes rears its ugly head, and that is unnecessary features in a project.  Let’s talk about that a little bit.

ALAN ZUCKER:  Sure.  So one of the really interesting things – and this really goes also with the notion of gold-plating.  We should never be gold-plating.  And people think you should build those extra features because that will really delight the customer.  And really a different way of looking at it is the effort that we’re spending to make that extra feature – make that thing a little bit shinier, a little bit slicker, a little bit cooler – we might be able to have spent that time developing three or four other things that might have cumulatively added much more value and really made the product that much better.

ANDY CROWE:  There are so many problems with gold-plating and extra features.  And recently a horrific security hole was found in a very popular operating system, and it was using an undocumented function call.  I’m sure some developer put it in there, thought it was a great idea.  We won’t document it.  It doesn’t have to go through all the quality process.  It doesn’t even have to go through all the security checks.  And then it left a wide-open door.  So there’s so many problems with extra features, which seem like they’re great.  Back when I first started, that was exactly what you said.  It’s a way to delight the customer.  And then you find out, uh-oh, you know.

ALAN ZUCKER:  And it also really plays in with the notion of Agile that I really like, which is building incrementally and just complete – and doing minimum viable products and building piece by piece over time, and you learn.  So if I’m able to get more feature and functionality into this build, that gives me greater opportunity to see what my customers like with what I’ve got versus really polishing it, because they may not really like what we’ve done.

And I love to tell the story about when we were building one of the applications, my customer said, “Alan, we want to get an email notification every time a file is loaded into the application.”  I’m like, “Guys, you realize there’s 16 billing runs.  Each billing run creates at least four files.  And then we have the opportunity for reruns.”  And it turned out we were loading like 350, 400 files a month.  I was like, no.  “We really, really need to have this feature before we launch the application.”  I’m like, please, no.  “No, we have to.”  So we built that feature in the application, you know, and it took capacity away from what we were doing at the end of this project.

First month in, first thing they said, “Dude, you are just crushing my inbox.  All I see is load notifications.  Can you turn that off?”  And that’s, you know, that’s a real tangible example where we built that feature.  We could have deployed earlier.  We could have used that time more wisely to do other things.  And it was something, it’s like, “Can you turn that off?  We really, really don’t like that.”

ANDY CROWE:  Ultimately, it represents waste for everybody.

ALAN ZUCKER:  It really did.

BILL YATES:  Don Norman is a guru on design, and he would agree with this 100 percent.  He talks a lot about, in his writing, he talks a lot about building features that we as the builder of those features and product, we’re convinced that they’re going to provide value.  And then they’re put out there in the wild, in the real world, and we see the customer either doesn’t use them; or, even if the customer asks for it, like in the example of this, they find it to be incredibly annoying and unuseful.  And so there’s a great lesson in there for me, both on the design side and then, after we have implemented features, we’ve got to go back.  We have to have that discipline to go back and ask the customer, “What are you using?  What’s adding value?  What’s not?  What’s annoying you?  What do we need to remove?”

ALAN ZUCKER:  And that’s really critical.  I mean, there’s two stories that come to mind.  One is, at one of the companies I was working with, we were setting up a process for bringing in project requests.  And it was this very, very complicated process.  Lots of handoffs.  It was beautifully architected.  And I said, “This isn’t going to work in the real world.  Too many handoffs.  Too much wait time.  Too much expectation that senior management’s going to be engaged.”  We implemented it, and it really just – it just was a huge waste.

Another thing is not too long ago I was working with this company, and we were setting up for their Agile transformation.  And we were talking about what did we want to capture in the trouble tickets, you know, that we were going to capture as part of the kanban board.  And the product owner and the tester were saying, “Oh, we need to capture all this other information.”  And, you know, it was a very interesting team, very interesting team dynamic.  The developers were introverts.  They were very quiet.  And I said, “Can you guys just be quiet for a second?  I want to hear from the developers because they’re the guys that are going to have to both do the work, and they’re the ones that will potentially benefit from having this additional information.”

So I said, “What do you guys want?”  And they’re like, “Now, that’s not going to help us.  That’s just going to be more work that we have to do to fill out these tickets.”

ANDY CROWE:  So a road construction crew got out to a job site about 25 miles away from their office; and the supervisor realized, oh, no, we’ve left all of our shovels back in the toolbox back at work.  So he called his manager, and he said, “I’m terribly embarrassed.  I know this introduces a lot of waste, and I’m really ashamed, but I’ve left the shovels there.”  The manager said, “Yeah, this is an emergency, and I’ll tell you what.  Since you won’t have shovels, why don’t you all just lean on each other until I get there with them?”

NICK WALKER:  All right.  With that, Alan Zucker, thanks so much for taking time to be with us.  We didn’t need any shovels today.

ALAN ZUCKER:  Thank god.

NICK WALKER:  And I can honestly say this has not been wasted time.  We appreciate you.  Also, we just appreciate, Andy, your humor and your insight.  Bill, thanks so much, as well.

We want to take this opportunity to remind our listeners of the double benefit you get from listening to these podcasts.  In addition to the valuable information from our guests, you also earn free PDUs – Professional Development Units – toward your recertifications.  To claim them, go to Velociteach.com and select Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and just click through the steps.

You can always visit us at Velociteach.com/managethis to subscribe to this podcast, to see a transcript of the show, or to contact us.  And tweet us at @manage_this if you have any questions about our podcasts or about project management certifications.  We are here for you.

That’s all for this episode.  Thanks for joining us.  Until next time, keep calm and Manage This.