Episode 1: Know the Scope of the Project (w/ Bill DeRouchey)

Corey: (00:10)
Hello, this is The Web Project Guide podcast, and this is Episode One: Know the Scope of the Project. I'm Corey Vilhauer, Director of Strategy of Blend Interactive. I'm the content guy. Later on talk to Bill DeRouchey, former Principal Designer at Zendesk, about his experience and understanding the scope of a design project as it gets spun up. But first, I'm joined by the development guy, Deane Barker, Senior Director of Content Management Strategy at Optimizely. Hey Deane.

Deane: (00:33)
Hey Corey. Good morning.

Corey: (00:35)
Good morning to you as well. I want a quick talk about what we're doing here. Deane and I wrote a book it's called The Web Project Guide. It's a look at the many stages of a web project, and what it takes to get something from an initial design, or an initial spark, all the way through to a launched and fully maintained website. Our goal was to write the book to provide context to those who might not be immersed in the industry like we are. That's our goal now, except now it's in podcast form. Each month we'll take one of the chapters from the book and talk to smart people about the topic of those chapters. Today we're talking about Chapter One, which is all about understanding the scope of the project. But first, Deane, I called you Senior Director of Content Management Research. That's a new title.

Deane: (01:30)
It's a bit new, yeah. For two years I was Director of Content Management Strategy, but it was much of a business role and I'm just a ridiculous content management idealist, and so I've become the Director of Content Management Research. It's my job to sit around all day and think about CMS. It's like the perfect job for me.

Corey: (01:50)
That's really fun. That's really fun. Congrats. Do you want to start a podcasting?

Deane: (01:56)
As long as we've got the stuff, and we're both in Zencastr, and have our microphones running, and are speaking to it as if we're doing a podcast: Yeah. Let's do one.

Corey: (02:03)
Perfect. Since this is our first episode, it only makes sense to start at the start. Deane, in the book you came up with this term, or maybe we came up with it, but I'm pretty sure it came from you. The idea of the initial spark, where did that come from?

Deane: (02:22)
I came up with the concept, was what I talked about. The Initial Spark was a marketing spin, because we picked the marketing theme of rocket launching. That's how we actually came up with initial spark. I believe that's how it's happened. The idea behind the initial spark was that there's a motivation to everything. There's a reason why you do everything, and you need to remember what that is when you started building your web project. Too many people get so deep in the weeds in a project, they forget why they started in the first place. The idea behind the initial spark is that there was a reason why you started down this path. There was a point of pain that you were trying to fix.

Deane: (03:01)
There was a goal you were trying to achieve, and make sure you don't forget that halfway through, because you can get so deep into the weeds that you forget why you started doing the project in the first place. You solve problems you didn't really need to solve. You had a problem, and you started this project to solve a problem, so don't forget to solve that problem. You can get all the way done with your project and realize, "Hey, we didn't solve the original problem we set out for." Have you ever heard the term yak shaving?

Corey: (03:27)
Yeah, I've heard of it, but please talk about it.

Deane: (03:31)
Yak shaving. It's a geek programmer reference that comes from a Ren & Stimpy cartoon. Yak shaving is when you start doing Task A, but in the course of doing Task A, you find something else that's got to be done. You get in there, and you're like, "Oh no, I need to do this other thing." Then in the process of doing that other thing, you need to do this other thing. The next thing you know, you started trying to solve Task A, and you're on Task G, and you haven't even got back to A.

Deane: (03:59)
Developers find this when they're programming all the time. They go into code to fix a problem, and then they see another problem that needs to be fixed. To fix that problem, they have to fix another problem. Next thing you know, you've been yak shaving for four hours, and you haven't fixed your original problem. Web implementation projects often end up as exercises in yak shaving. You solve all these other problem, and you forget to solve the original problem.

Corey: (04:22)
I didn't know it was a Ren & Stimpy reference at all.

Deane: (04:25)
It is. I don't remember what... Actually, I have the reference, and maybe I'll provide the link in the transcript or something, but I have the reference to the Ren & Stimpy cartoon. It was a developer at American Express, just came up with it. Someone asked what he'd been doing all morning, because he'd been doing this problem of solving problems that didn't need to be solved. He had watched the Ren & Stimpy cartoon last night, that had them shaving yaks. He announced that he'd been yak shaving, and it just took on a life of his own.

Corey: (04:52)
This is one of the reasons I really enjoyed writing this book with you Deane, and I hope you got the same amount of random, barely relevant little stories. You probably learned a lot about the movie. This Is Spinal Tap, and WrestleMania, I'm sure

Deane: (05:05)
Corey, you are a walking non sequitur.

Corey: (05:08)
I should be offended by that, but I won't be. No, this idea of understanding the initial... This is a thing that we run into at the initial scoping and content phase, is we are putting together a site map, or we're putting together some kind of content plan. There's a difference between the long list of requirements that might have been brainstormed at some corporate meeting, or someplace, and the actual content that is required for the actual site itself. When you're coming up with this initial spark, when you're trying to figure out, "What's the reason we're going to do this in the first place?"

Corey: (05:45)
At what point is the CEO's blog a part of that? Will it be a part of that at all? Or is this just a thing you tacked on, because you have to pull some kind of ownership with that corporate level? How often do you think weird, random things, are literally thrown on at the end, because the wrong people are in the room, or they were consulted too late, or they weren't privy to this initial spark? How do you communicate that?

Deane: (06:12)
I think a lot of this happens is that there's a corporate cynicism. Somebody hears, "Oh, somebody's going to do something with a website," but there are people in your organization that automatically think, "Well, that's never going to go anywhere, or they always talk about that." But if they keep hearing about it, and it starts to gather momentum, and they're like, "Okay, I keep hearing about this. Maybe this website project's actually going to come off." 65, 70% of the way through the project, suddenly they're convinced this is now actually going to happen, so now they very much need to be a part of this. They didn't deign to stoop to your level when they didn't think you were going to succeed, but when it looks like you actually have some momentum, suddenly everybody wants to get their stuff into your project. That happens all the time.

Corey: (06:51)
It sounds really cynical, but I think it also sounds very real, in that I think the initial group that decides what a project needs to be is usually smaller than it needs to be. Then it gets big, and those initial thoughts have been lost.

Deane: (07:09)
There's an ongoing in our business, there's this ongoing joke. It's not really a joke. It's kind of an understanding that we end up being corporate counselors, a lot. Corporate therapists. We'll come into organizations... When I was back in services, when you and I worked together at Blend, I used to go in and do a lot of high level consulting. You would go into organizations, and just help them get their crap together. You would sit down at a table, and realize that this organization is suffering from some level of dysfunction. How do you fix this? But you mentioned cynicism, and I'm just wondering to what extent our job involves managing cynicism? There's a tendency to get very, very cynical, because how many web projects fail? What percentage fail? 60%? 70%?

Corey: (07:58)
I guess it depends on what your definition of failing is.

Deane: (08:00)
Yeah. Failing's not binary. It also depends. I would say a less number of fail, that engaged with competent outside support, but internal projects had this huge, massive failure rate. There's a tendency to just be wildly, wildly cynical about these projects. Part of our job, and part the thing that you do in services, and that I did when I was in services, is just manage cynicism by managing expectations. There was a guy, Corey, you knew him. He used to do sales for Blend way back in the day. He was a master of... What do you call pit the old folksy sayings? Yes. He was a master of these, and you know what I'm talking about. He had a saying that was, "Happiness is reality minus expectations."

Deane: (08:54)
If you take where you ended up, so if you ended up at a 10, their expectation was a 13, well, your reality is not a negative three. You're underwater because the expectations were higher than the reality. If the reality was a nine, well, the net there is one. You're doing okay. But if the reality was only a two, and you delivered a 10, you're doing really well. The idea is, for a project to be successful, and this is a hugely cynical point... For a project to be successful, you either deliver really great results, or just keep expectations really, really low. That's horrible. That's horrible, but it's true.

Corey: (09:30)
It's absolutely horrible, yeah. But realistically, if you think about, we're people in the web industry. We've been in the web industry a while. We wrote this book for people who are the Director of Marketing, or your Procurement Team. The difficulty here is that you have to try to provide expectations. We'll actually talk a little bit more expectation-wise in the next episode, but you have to wrangle a scope and maintain expectations. A lot of times with people who aren't just clients, they're your boss. They're people who really control a level of budget, and with that, there's a power imbalance, obviously.

Corey: (10:10)
You have to know the right questions to ask, that you can push it toward a real role, and a real purpose, versus just rolling over and saying, "Yeah, yeah, of course. We'll put that in, because if we don't put that in, you won't approve the budget on this." Is there anything... What kinds of questions do you always have to try to overcome when you have to help a client pitch this to the C-suite or pitches to the Procurement Team?"

Deane: (10:39)
No, but here's an important point, going back to what you said earlier, is that there's very different power dynamics between a project that's being done internally in an organization, and a project in which you're hiring an outside firm. You work in paid services now. People pay you to do stuff for them. If it's an internal project, everybody's on the same team, and you can keep expectations low, and everybody's worked towards the same goal on the same team. But Corey, if somebody is paying you a large amount of money to come in and provide something, and you work really hard to keep their expectations low, that suddenly raises questions like, "Well, why are we be paying you if this can't possibly be delivered?"

Deane: (11:20)
If everybody in a room is on the same team, it's easier to talk about lower expectations, because you're all on the same team. You all go through the same things every day. You all work with the same people. You understand that there is some level of dysfunction on every organization. But you, Corey, as the consultant that comes into the outside, you're supposed to be magic. You're the one who's supposed to make everything work, and people hire you because they're sick of their internal dysfunction and internal low expectations. So Corey, when you walk in the door, the cloud's part, and the sun beam comes through, and the angel starts singing, and everything works out. You have the unenviable position of trying to manage expectations against your own self-interest, because people are paying you for high expectations.

Corey: (12:02)
Absolutely. Absolutely. Well, it's time to take a very small break. Here in a sec. We're going to talk to Bill DeRouchey. He was previously Principal Designer at Zendesk, and now he's working on a book that's forecasting potential career opportunities for today's young designers, which is very cool. But first, this episode of The Web Project Guide is brought to you by Blend Interactive, a web strategy and design development firm, dedicated to creating and maintaining custom content management projects. I work there, which is why this is brought to you by them.

Deane: (12:31)
I used to work there.

Corey: (12:32)
And Deane used to work there.

Deane: (12:34)
I hired Corey to work there, as a matter of fact.

Corey: (12:36)
It's true. About 11 and a half years ago, Deane brought me in to spin up a fledgling content strategy practice, and here we are today. Anyway, Blend's been building big content-focused websites for 16 years, and we're always looking for our next big project. Visit us at blendinteractive.com.

Corey: (12:58)
All right, let's welcome our guest, Bill DeRouchey. Hi Bill.

Bill: (13:01)
Hey there. How you doing?

Corey: (13:02)
Good. How are you?

Bill: (13:03)
I'm doing well.

Corey: (13:06)
Behind the scenes... We do this over Zoom, and Deane's got a smirk on his face. I can imagine he's only thinking of me under the blanket in the office right now, to soundproof my recording.

Deane: (13:17)
Corey has an incredibly high tech recording studio, involving a blanket pulled over his head, which confirms everything I always suspected about Corey Vilhauer.

Corey: (13:26)
Let's ask some questions. I wanted to talk through... In the book, this chapter specifically, it's the first chapter of the book, and we're really focusing on this idea of, "What is the initial reason? What is the initial spark, that leads to specifically a project? What is the point in which a reason is found for a new project?" For you, in your life as a Product Designer, what kinds of initial sparks would you commonly see? What were the common reasons that somebody says, "Okay, well let's start doing this specific thing."

Bill: (14:03)
A little bit of background. Most of the recent jobs I've had, have typically been in medium-size, enterprise-size companies. The roles that I were usually tackling, were going after some technical debt, experienced debt. Usually those initial sparks, some kind of a reaction to something that's been broken for a while, or at least it has been problematic for a while. Often these problems have been well-known, long-ignored, and now it's time to finally tackle them. Those sparks to finally do those in addressing that debt, accumulating customer complaints is a good classic one. Responses to competitive pressures, or even just the realization that, "If you actually were to fix this thing that's been sitting around far a while, that could unlock other capabilities that the company needs to do." A spark is often... It's a reaction to known problems.

Corey: (14:59)
I imagine that everybody probably has different reasons for deciding they want to start something. How do you vet? How do you take somebody's reason, and determine whether or not it's a reason, or if it's just some issue they have that day that's annoying them?

Bill: (15:14)
It comes down to a question of priorities, because there's rarely just one problem inventing the problem. Usually there's multiple problems, and it's more of a question of, "Which one do you tackle?" As opposed to, "Is this one valid or not?" That comes down to wearing multiple hats. As a designer, if you focus only on the customer's perspective, then you're going to probably see a ton of problems to fix. At that point, you have to also start wearing the engineering hat, and wearing the business hat as well, to understand all the different perspectives of, "Should this be the thing that we tackle next, or not? In vetting it, there's understanding the customers and their challenges, but it's also, "If you were to provide... if you were to fix this one thing, what would it unlock?" A lot of times, if you got, let's say, five things at hand, but one of them, if you tackle Problem A, that might help chip down the problem of Problems, B, and C, and D."

Deane: (16:10)
How do you vet solvable problem from an unsolvable problem? "We want to quadruple our business by next Wednesday," and it's just not possible. You have customers that come in that are blaming their digital presence for larger problems. They have terrible governance, or they have internal dysfunction, or they just have a crappy business model. What do you do in those situations? That can get a little delicate. Nobody wants to know their baby's ugly. Nobody wants to know that their fundamental business model is jacked up.

Bill: (16:41)
Interesting question, and I might have to the sidebar on this one, because are we talking about in a consulting situation or in-house?

Deane: (16:47)
This funny, because this comes up all the time. In-house, everybody's on the same side, but when you're a consultant, they are paying you because they think you're the smartest person in the world, and you're going to solve all their problems by snapping your fingers. Let's do both. Let's compare and contrast. If you're an external consultant coming in and the customer, the prospect, the client, has come to you with a problem you think is only barely related to their digital presence, and has much deeper systemic roots. What do you do in that case?

Bill: (17:13)
You start digging down, because a design problem, if dig further, it usually becomes a business problem at some point on the line. At some point, it becomes an organizational problem. Some point it becomes... Their core assumptions might be wrong. It almost has to be a discovery process at the beginning, to understand why they're asking that question in the first place. Why they think it's a problem in the place. It's a lot of stakeholder interviews just to understand why they're asking that question. More often than not, stuff shows up. There's always layers underneath. Especially if you start asking multiple people in the company, multiple stakeholders if you will, and then finding the patterns across that.

Bill: (17:49)
What you could do is, you could say, "Sure, we could fix this problem, or actually give you the solution you're asking for," but then project a bit out and say, "In a year, you might have the exact same problem that you originally had." It does get understanding their business, their business model, in order to really understand why they think this is a problem.

Deane: (18:10)
How does that differ if you're internal? If you're working on an internal team, are there different dynamics to that? Everybody's technically playing on the same team.

Bill: (18:19)
A bit of politics starts showing up when it's internal.

Deane: (18:24)
No kidding.

Bill: (18:24)
Yeah. You know, go figure. That's not really news. In-house, versus consulting... In-house, you're allowed to see a lot more longer term. You've been around, well, usually... If you've been there for a while, you're going to have just more context, more background, more understanding. The organizational challenges often become more apparent when you're in-house, which is a, "Duh," but you can start seeing the dynamics of how different groups might be tackling the same thing. The last few corporations I've been in have been 5,000 people, and before that it was 200,000 people. You can start seeing the overlap in between different stakeholders, and also recognizing why they met the positions that they do.

Deane: (19:10)
How much do you think territorialism plays in these projects? How much do you think it weighs these projects down? I've always maintained that there's a group of people inside every company that doesn't want anyone to dig up the dead bodies.

Bill: (19:21)
A little bit, but I think that territorialism doesn't come out of nowhere. You will have individuals who that's just their nature, and it's hard to work around that. What happens is, a lot of times, especially if you have different product groups whose missions overlap, but are almost hostile to each other. That's often because they are being held to different outcomes, and different metrics of success. If each in individual group is being held to different metrics of success, they're going to naturally be hostile to each other. Their job is on the line. They're expected to deliver a blah percent, in X months, where another group might be being held to different things. Those groups are being run at cross-purposes, so it becomes, in a way, an organizational question. If different groups are being at least held to aligned goals, and aligned measures of success, then they're going to be more likely to work together, rather than be hostile to each other.

Deane: (20:23)
We've had a lot of conversations about internal team dynamics, and internal policy dynamics at an organization. To what extent do you think organizational health, or dysfunction, plays out in these projects?

Bill: (20:37)
It's almost everything. If there's dysfunction, projects will reveal it, especially if you are tackling a... I don't want to call it significant, but let's say a wide problem. A problem that spans groups. That'll reveal whether an organization is functional or dysfunctional pretty quickly. That does come down to culture, or you could even come down to history. In both situations that I've been in recently, there have been acquisitions. Acquisitions are hard to integrate culturally. It just takes time. There's really no way around it, except for time. You don't really get that smooth integration immediately.

Corey: (21:19)
We run into this a lot on the consultant side, where you can see that there are things being held back, because there is some sort of shared history, and they just won't even bring... Even if the initial idea is beneficial to the overall organization, or even beneficial to even a piece of the project, they're a little reticent to bring it up because they have this history. They know it's not going to go well, once it comes up, which is a total bummer. Again, I think Deane mentioned this earlier, but sometimes as a consultant, we get to be the shining knight who rolls in and says, "We think you need this."

Corey: (21:59)
There's a handful of people who are like, "Yeah, we've been saying that for a while, but you need to be the one who said it out loud." What I'm curious about is, how do se that initial spark, the realization around it, the ideas that have led to an actual project? How do you see those documented in a way that when it gets further down the line, there isn't a, "Well, I thought you meant this, and actually we're doing this now." Where have you seen that being transitioned into action, and how is it documented so that people can use it and jump in later on?

Bill: (22:30)
There's almost an initial discovery that needs to happen, especially just in terms of digging at the assumptions behind those documents, because corporations tend to have their own language in how they describe things. They could probably, are often using terms, or even acronyms, or concepts, that they just take for granted, that you as a consultant may not have the same shared understanding going into it. If you don't have it as a consultant, then the end-customer probably won't have that as well. If the initial requirements doc is going to be given to you, almost as peer-insider baseball, then it just needs to be teased apart.

Corey: (23:12)
This is definitely a thing we've seen a lot of times. It's like, "Here's our 700 slide PowerPoint, that outlines all the reasons, and purpose, and all this stuff." Then whoever is next in line to work on this project gets at... You still have to have the same conversation, because there's a lot of nuance that isn't discussed, and there isn't a lot of... You have to understand the project from the angle of whatever process is coming up next.

Bill: (23:33)
I think what helps there is also just helping to document the problem itself, more than the solution, because more often than not, whatever solution you're going after, it won't tackle, it won't address or solve 100% of the problem. There will be some other angle of the problem being waiting to be fixed later on down the line. The more you can be clear about the dynamics underlying the problem itself, that's going to help the next team down the line be able to better check on their piece of it.

Corey: (24:04)
I do have one more, very important question.

Bill: (24:07)
Uh-oh.

Corey: (24:08)
Bill, you've been lucky enough to meet Mike Watt, right?

Bill: (24:11)
Not in any depth, but yeah.

Corey: (24:16)
What's your favorite Mike Watt song?

Bill: (24:17)
Oh Jesus. Okay. My favorite Mike Watt's song is probably 'The Glory of Man'. I literally have Scrabble tiles laid out behind me for an art project I'm trying to do. I don't know, it just grooves. Favorite Minutemen song is a rough one though. It's a great love song.

Deane: (24:34)
I literally am just Googling this guy while you're talking.

Corey: (24:37)
Yeah. Deane doesn't know this. I actually fell into Mike Watt, and Minuteman, and Firehose, and that whole group of random bands that he was in. Not random bands, I guess they were all pretty much the same band, minus one person. The first Mike Watt I ever heard was his first solo album, which I think came out in the '90s, and it was him and a bunch of '90s grunge.

Bill: (24:59)
Oh yeah. 'Ball-Hog or Tugboat?', I think it was?

Corey: (25:02)
'Ball-Hog or Tugboat?' is one of my favorite albums of all time, still. I'm a big... Listen, Eddie Vedder's best song was "Against the 70's", so. [crosstalk 00:25:10]

Deane: (25:10)
Me too. I like that one too. That's a good collection of songs.

Corey: (25:17)
I knew you'd like that one, Deane. Hey Bill, what are you working on right now, other than Scrabble art projects?

Bill: (25:24)
I'm working on a book. It's a book that has been in the back of my head for a few years. Trying to put some life to it. It's essentially trying to take a... A longer [inaudible 00:25:36] "What does the future look like for today's young designers?"

Corey: (25:39)
Mm-hmm (affirmative).

Bill: (25:40)
I've personally gotten to that point where my career is a bit more on the down slope, versus the up slope. I'll just say that delicately. It makes you look back to when you were 25, and just starting out. It makes me think. "Well, so for today's youngins, what could their future look like?" Knowing that I could not have predicted my design career at all at that age. It's a bit of futurism. It's a bit of memoir. It's a bit of just monkey around with the word design. It's kind of a mess right now, but it's trying to take shape.

Deane: (26:13)
I'm going to warn you against writing a book. It's just not worth it. I guess it depends on how good your co-author is. Speaking for Corey, I can assure you: wasn't worth it.

Bill: (26:23)
Nice. Nice.

Corey: (26:24)
All right. That's it; we're done now. All right. Thanks Bill.

Bill: (26:27)
Thank you very much. It's been fun, guys.

Corey: (26:29)
All right, bye.

Deane: (26:29)
Bye.

Corey: (26:37)
All right, we're back. We're back from the interview, Deane.

Deane: (26:40)
Okay. Hey, good interview.

Corey: (26:41)
Yeah. Great interview. Thanks to Bill. A little look behind the curtain, we're actually recording our interview with Bill after we record this, so don't tell anyone.

Deane: (26:51)
We didn't come back from the interview. The interview consists of Corey saying, "Hey Deane, we're back from the interview."

Corey: (26:56)
I'm sure it was great. Bill's awesome. Anyway, any final thoughts on this, Deane?

Deane: (27:03)
None, except just make sure you keep your original purpose in mind, and don't stray too far from it, because I promise you that every single thing that happens during your project will try desperately to pull you away from this original purpose. You need to keep it in mind. Write it on a post-it and stick it on your monitor, so you look at it every day, and you remember why you're doing the project in the first place, because I promise you, you will lose sight of that.

Corey: (27:27)
Great. That's our show. Thanks to our guest Bill DeRouchey. He's got a book coming out in the near future, which we who have written a book, know means it's coming somewhere between six and 600 months from now. That book focuses on what career opportunities will be out there for today's young designers, so keep an eye out for that. The Web Project Guide is a product of Blend Interactive. Blend Interactive is a web strategy design and development firm dedicated to making great things for the web. This is one of those things.

Corey: (27:55)
The Web Project Guide is also a book. You can order the book at www.webproject.guide, or you can order it internationally on Amazon. It's a beautiful book, but if you're not a book person, you can also read the full text online. This is Episode One of The Web Project Guide, which also corresponds with Chapter One of the book, Know the Scope of the Project. Visit webproject.guide/reasons and catch even more resources on this topic. We'll be back next month with another episode, and until then go do amazing things.

Deane: (28:23)
Good luck.