Episode 2: Set Your Expectations (w/ Karen McGrane)

Corey: (00:11)
Hello, this is The Web Project Guide Podcast. And this is episode two, set your expectations. I'm Corey Vilhauer, Director of Strategy at Blend Interactive. I'm the content guy. Later on, we'll talk to Karen McGrane. One of the three partners at Autogram about her experience setting expectations and clarifying scope at the start of a project. But first I'm joined by the development guy, Deane Barker, Senior Director of Content Management Research at Optimizely. Hey Deane?

Deane: (00:35)
Hi Corey. How are you?

Corey: (00:37)
I'm good. If you're new to the podcast, here's the pitch. Deane and I wrote a book called The Web Project Guide. It's a 24 chapter romp through the different phases of a web project, all written to provide context to those who might not be immersed in the industry. Like we are. For this, we take one of those chapter topics and talk to smart people about that topic. So today we're talking about chapter two, which is about setting expectations at the start of a project. I really appreciate Deane the way we have the script set up, because it says that now Deane will say something and we'll segue into the topic. So go ahead and segue into the topic, Deane.

Deane: (01:16)
It's funny because I feel like we talked about expectations a lot in episode one. I mean, that's [inaudible 00:01:20] was largely about setting as expectation. So hopefully we see something new here in episode two, I'm going to set your expectations now that we're probably going to repeat ourselves a lot [inaudible 00:01:30].

Corey: (01:30)
So a project begins, when we jump into a new project and start making big plans for what it's going to be, when we move from that initial spark into action. It's really easy to get caught up in what we could do in the limitless expanse of a new project. But as we all know, that's not really how things work. Deane talk about the idea of inflection points of the idea that you can have it fast. You can have it cheap. You get to pick two of a fast, cheaper or good.

Deane: (02:02)
Oh yeah. That's that saying, right? You can have a fast, cheaper, good pick two. And I don't say pick two. I say, pick the one you don't want and that's where your project bends. So when we talk fast, cheap, and good, we're really talking about scheduled budget and features. And you need to decide on your project, which is the one of those three that can flex, which is the inflection point, because something will have to flex. Nothing goes perfectly. And I give you some examples in the book here. So if you're limited to spending $250,000, you have a rigid budget has to be delivered by the end of the year. So you have a rigid schedule. So you want as many features as possible within those boundaries. So you are flexing, your flexion point is good or features.

Deane: (02:55)
The next example was they have a CMS that's not compatible the new CRM project that goes in on June 1. So they get a rigid schedule and they have to have integration with a CRM. So they have a rigid feature and then they can spend whatever they want. That's pretty rare, but that's your flexing on budget there. And then the fourth example is that they have limited funds. So they rigid budget. They want a super high quality product, so they're origin on their features, well, the inflection point there is schedule. They're going to flex on the schedule. You can get really great features at a low cost. It's just going to take a very, very long time, because you're probably going to have to do it internally and steal resources from somewhere else. So the hack need phrase is you can have a good, faster, cheap pick two. Don't look at it that way. Look at it as which one of those three am I willing to give up?

Corey: (03:40)
I feel like we've really seen this play out in almost every project we've ever done. Honestly, almost every project comes in with the idea that they're going to get all three of these things. They don't want to flex on anything specific. And we find, I think more than anything that that schedule is the one that's allowed to flex when there's any rigidity or if there's rigidity in all three of them, that schedule is the one that gets to give the most. I think that there's just less, I don't know if there's just less of a cost to it. When you were back selling things, when you look back in retrospect on any of these projects, where are the places where the flex burst out and had the biggest issues?

Deane: (04:25)
Okay. So let me put you at the end of a project. So you are supposed to launch, you're the tail end of the project, and you're not going to make it. So let's talk about the three different ways that we could flex when you realize you're not going to make it. [inaudible 00:04:40] you could flex on budget. And to flex on budget, you would have to bring in more resources, which hardly ever works. It needs to be said does not work really well. But if you're going to flex on budget, then you somehow throw some money at a subcontractor or someone else to increase your staffing for the project. So that's your flex on budget.

Deane: (04:57)
Your flex on schedule is even simpler. You just push the data out, so you're not going to make it. Okay, well, we'll launch a month later. And then flex on features is the classic example of when feature use get thrown overboard, the classic cliched phase 1.1. Well, those who go in and phase 1.1 or phase two or whatever and they hardly ever do. They get thrown overboard and they don't somehow get on board, but those are the three ways that you can flex a project at the end. Either throw more money at it, push your deadline out, or start throwing features overboard.

Deane: (05:27)
The one I see most often, I think far and away is schedule people, push their launch dates out. Honestly, many launch dates are just random and arbitrary anyway, and they're just going to pick the date. We need to launch by there. That would be great. And they either realize they're not going to make it, or they realize the end product is really great and they want it to be really good, and they don't want to skimp on it because they're proud of those things they've done. So you push the data out to make sure you have a continuing amount of quality in the project.

Deane: (05:55)
So flexing on schedule is most common. Next, most common is going to flex on features, features get thrown overboard all the time. I think it's less common to flex on budget. A lot of people are really budget constrained. Also, and I've said this before, and this is very well known in the development and IT industry is throwing budget at things doesn't always make it go in faster. We have had clients that have bitten off more than they could chew. And the biggest thing is content migration. I mean, you and I both know this. Clients swears they're going to do content migration. They're going to move the content from the old website to the new website. They swear up and down that they're going to handle this to save money.

Deane: (06:30)
And then they realize it's a shocking amount of work and it's going to take them months to do, and they're going have to pull people off other projects and they don't get started. And then towards the end of a project, they realize that they need help. And so they find another hundred thousand dollars to subcontract the content migration. When I worked at Blend Interactive, we had a project with a university. Corey, I believe that project was delayed 18 months at the end because the customer had not migrated the content.

Corey: (07:01)
Yeah. That exactly what it was. In fact, I ended up migrating the content for that.

Deane: (07:05)
The website was done and sat empty for 18 months.

Corey: (07:09)
I think you realized when you get to a certain point that schedule, that timing, it is really the only thing that is by definition, finite. You can't make time slower or faster. You can always try to raise more budget. You can always try to remove features, but time you can't change time. So it always ends up getting pushed out.

Deane: (07:32)
Some schedules are more rigid than others. You do have situations. I saw this many times in my services career where they were going to lose a license to their existing CMS, or they had already canceled their existing hosting plan or something. And the clock was ticking and it had to go in. And that is clarifying in some ways. I mean, when you time box a project and we are launching on the first of the year, no matter what, that's very clarifying. And you really start to drill down to what are the most important features of this project. Literally, if we had to just get something in, what would it be?

Deane: (08:11)
And so when you start looking at your schedule and you pick the launch date, ask yourself questions at that time about how rigid is it? Did you pick that launch date just because you had to have a date? Did you pick that launch date because your boss said, "I will only give you money to do this if you get it in by this date?" Or did you pick that date? Because there is some outside pressure, some outside force that is going to do damage to your organization if you don't launch at that time. And that'll tell you what your ability to flex is on time.

Corey: (08:36)
What I find for someone who is in the position to set expectations and set a timeline and decide which of these three things we're going to flex on. If a timeline is a thing that cannot be flexed, the expectations around that for everyone involved, you almost need to over exaggerate how long it will end up taking, because what ends up happening is there's a giant crunch at the end, no matter what. Because everyone thinks there's enough time to get something done. We've done a handful of projects, I guess recently that that were tied to like an event we had to... You just end up working super hard that week before because you just didn't make decisions fast enough early on. And every single one of those missed decisions early on cascades down to the end.

Deane: (09:30)
Yeah. And you need to understand, this is going to sound ridiculous, but understand these dates will eventually happen. And it's very easy to look at a date and say, "Wow, that's so far off in the future." But someday it will be there. And you need to, when you set your date, start looking at what's happening in your organization around that date. The first of the year, terrible time to launch a website is a terrible time because the month before the website launches is going to be a brutal crunch time and you don't want that to happen in December.

Deane: (09:57)
Terrible [inaudible 00:09:58] launch and website is over the summer because a lot of people are out on vacation. You launch a website in the spring or in the fall because then the month prior to launch, you can be sure that there's all hands on deck. Especially if you're doing a migration with a big QA component, you need people from all these different departments to QA their own content. You need all these content owners present. So when you set your date, literally communicate that to the team and say, "Don't schedule vacation two weeks prior to the date because we will need you available."

Corey: (10:25)
We'll talk about this with Karen here in a second. Our guest today is Karen McGrane. She's a good friend and advocate of The Web Project Guide. She's a long time paragon of user experience and content strategy. She's also one of the three founding partners of Autogram, which is a firm dedicated to shaping content management systems around design systems. But first this episode of The Web Project Guide is brought to you by Blend Interactive. Blend is a web strategy design and development firm that's dedicated to creating and maintaining custom content management projects. Deane helped found it, I still work there. We've been building big content focused websites for 16 years and we're always looking for our next big project. So visit us @blendinteractive.com. It's guest time. We're excited to welcome our good friend Karen McGrane to the podcast. Hi Karen?

Karen McGrane: (11:21)
Hi Corey and Deane?

Corey: (11:23)
How are you doing?

Karen McGrane: (11:24)
I'm great.

Corey: (11:25)
Good.

Karen McGrane: (11:25)
How are you all?

Corey: (11:26)
I'm good. I hear that Deane wants to say something to you.

Deane: (11:31)
This chapter that we are talking about in this episode is setting expectations and managing expectations. And there's the cliche in this industry that Karen, I know you're aware of, of our role as corporate counselors and therapists. How incredibly cynical is it for us to try to keep our customers expectations low? Is that cynical? Or is that perfectly valid self-defense for a paid consultant?

Karen McGrane: (12:04)
Oh, I think it's perfectly valid for a paid consultant. I think in the sense that many organizations don't actually know what they want and our job is to manage expectations around what they're going to get. I think a lot of organizations don't have as much insight as we do into how long things take or particularly what things are complicated and what things aren't. What's difficult to pull off and what's relatively straightforward to pull off. So to me it seems like managing expectations is just being a good communicator and moving from the benefit of saying, "We understand this space in some ways better than our clients do and it's our job to help them understand what's going to happen to them."

Deane: (12:59)
So there's a tendency in pay over promise. Consultants are legendary for that. And when you're being paid to come in and solve a problem, are you working against your own self-interest if you try to be realistic with the customer about their problem? Because I could envision a scenario when the customer wants something incredible and you know that their expectations are wildly unrealistic. And so you come in and explain to them what's possible and your vision of what's possible is not worth it to them. And so they were to cancel the project. So do you think there is a tendency in paid services to over promise in order to capture potential consulting income?

Karen McGrane: (13:49)
Well, I definitely think there's a tendency among salespeople to over promise, but I think that, that in many cases is a function of how salespeople get compensated. So if you're working with a big agency, your salespeople are going to be compensated by how many deals they close and by the revenue coming from those deals. And so to a certain extent, they're incentivized to try to close things, even if it means over promising. I think that something that someone said to me once is that the person in your organization with the power to say no, has to be more powerful than the person who can say yes.

Karen McGrane: (14:29)
So you've got to have somebody in your organization who the salespeople are terrified of. Who's managing the revenue and managing the budgets and managing the scope of things and whose job it is to ensure that you as a client services firm are not getting out ahead of yourselves in over promising in a way that you can't deliver on, or that will cause you to not be profitable on the project.

Karen McGrane: (14:56)
To me, that's just healthy business management. I really think that people who are doing consulting work and who are responsible for development work, are much less likely to over promise. There may be cases where, I mean, I'm sure we've all had the experience of trying to get time estimates from developers. And they're usually wildly under scoped. It's like take the estimate somebody gives you and double it. I also don't think that's a function of poorly managed expectations. I just think it's a function of learning how to scope a project is a skill undo itself. And many developers don't have the perspective needed to provide really accurate estimates. But again, that's why you have somebody in your organization whose job it is to ensure that you set expectations correctly and you charge for things correctly. And if you know that a developer always wildly overestimates what they're able to get done. Yeah. Double their estimate.

Deane: (16:09)
How do you get clients to, we talk about scope creep in terms of... It's very easy to identify technical scope creep.

Karen McGrane: (16:18)
Right.

Deane: (16:19)
In fact, I think it's this episode, Corey, that you and I talked about, yak shaving. Karen, are you familiar with the term yak shaving?

Karen McGrane: (16:25)
I am familiar with the term yak shaving Deane.

Deane: (16:27)
Right. So we go to do task A and then we start doing task B and we're in task G and we haven't done the original thing we were planning to do. What we talked about for the first episode, the idea of keeping your eye on the original reason why you started the project. How often do you need to drag clients back to reality? And there's a tendency to bite off more than you can chew. And how often, and how delicately do you have to drag clients back to the table and say, "Look, this was the reason why we started this project and we've taken our eyes off this."

Karen McGrane: (17:01)
I think it does differ sometimes based on the type of project that you're doing. And I was thinking about this last night as I was preparing for this. And what one thing that's striking to me is the difference between doing a project where, you know the end result has to be a functioning website. And doing a project that is more strategic consulting, where you're helping to define what the goal of the project is or you're helping to uncover what the actual problem is. Those two types of projects are different because the end states obviously different. Managing expectations around a project where the end goal is a functioning website. Those, I think tend to be more featured driven or just scope driven. Like what are we building? Does that thing work? Have we curate it? Do we agree that this is something we could release to the public?

Karen McGrane: (18:03)
Whereas a more strategic consulting project, yeah sometimes I think you really do have to keep reiterating to the client. Here's why we are doing this engagement. And here's what we expect to get out of it. Because when you go into a project like that, the end state is so much more fuzzy. You don't what the problem is. So you don't know where you're going to get to throughout the course of the engagement. So continual reminders around why you're doing what you're doing and what sorts of insights you're expected to uncover. I think that does help keep everybody on the same page.

Corey: (18:43)
Karen, I really like the idea of the person who says no, being more powerful than the person who says, yes. I'm thinking around the idea of somebody who might read this or listen to the podcast, read the book who, they're not necessarily maybe hiring an outside firm. They're the person themselves who are in charge of this. And they become the person who has to say no. And the person who is saying yes is their boss, their CEO, or something-

Karen McGrane: (19:15)
Sure.

Corey: (19:15)
...that has big wild ideas. What are some recommendations obviously, sometimes can be an unsolvable problem. But what are the types of things that you always recommend to help them be able to set some level of expectations, even though they have these gigantic high level goals, they're really going forward.

Karen McGrane: (19:33)
Sure. I think learning how to set expectations with your boss is just one of those skills that everybody has to work through in their career. And it doesn't necessarily mean that a website comes out of it at the end. It's just that a lot of times, in today's modern capitalistic society, employees get tasked with too much responsibility. They wind up with a boss who's perhaps not clear about what their expectations are or not clear about how much that person has on their plate.

Karen McGrane: (20:06)
And so learning how to articulate the trade offs and manage up to your boss and say, "Okay, last week you told me you wanted to do these things. And this week you're saying these things, what should I focus on? And can you help me prioritize here?" That's something pretty much everybody has to do in every organization. I mean, some of the things with high flank stakeholders see going into the project, shedding on everything, highest paid person's opinion kind of things like those are, I mean, you're never going to escape those.

Karen McGrane: (20:48)
I think challenges like that. I just treat it as like, that's just part of the job. If things like that are happening to you, it's not a sign that you're doing something wrong. It's just a sign that those things happen and your job is to figure out how to manage them and how you manage them might not even be the same way every time. It's just, you need some diplomacy and you need to be able to finesse some decision making.

Corey: (21:15)
Sure. You have to understand the type of person who's in that role. Specifically in the client side, I've worked with clients who are very big picture and they don't really understand as gross as the term is how the sausage is made and they just expect magic to happen. And then there's also sort of the other side, which can be just as overbearing, which is somebody who's been deeply in this work before and has very specific ideas of what they want done. And in that case, I guess both of those sets of expectations are, they're very different, but also very difficult to overcome. Because you've got one person who wants it done a specific way and you have another person who wants it done, just however. But also in a specific way, ultimately.

Karen McGrane: (22:00)
I mean, I have been doing this for a long time and I think anybody who grew up in the early days of the web, I think is overly accustomed to working with clients that don't necessarily know how the sausage gets made. And having to do a lot of hand holding and a lot of explaining because it's all new to them. And you're this 30-year-old kid who was coming in to tell them how to run the business. And there were a lot of really frustrating times because we were having to explain an entire new industry to people that was changing how their whole business operated and they didn't understand it.

Karen McGrane: (22:43)
Today I really find that I work with a lot more clients that do understand what it is that we're doing and we're able to have higher level conversations because we don't have to spend a lot of time explaining the basics, which personally I like a lot. If you're going to be encountering clients that can speak and talk and think about the problems on the same level that you do. Yeah. I mean, in a lot of ways you have to manage expectations more carefully because you're talking about the real things you're actually going to deliver, rather than just talking them down from their flights of fancy.

Corey: (23:30)
Sure. You mentioned the work you do now. I wonder if you want to talk a little bit about Autogram. What's Autogram all about?

Karen McGrane: (23:38)
I do want to talk about Autogram.

Corey: (23:39)
Why are you so special Karen?

Karen McGrane: (23:42)
Well, I'm very special because I work with two business partners, Jeff Eaton and Ethan Marcotte one, or both of whom will undoubtedly show up on this podcast at some point. So we all have worked together off and on over the last 10, 15 years, it's been a long standing dream of my life to get to start a company with those two guys. And I finally made it happen last year. So our consulting practice focuses on the intersection between content management and design systems and the pain points that organizations face today as they are trying to adopt a more modern tech stack, trying to improve the publishing processes and workflow internally.

Karen McGrane: (24:31)
And I hate to throw around buzzwords like digital transformation or whatever. But organizations that are moving into a, I would say more operational phase of their digital transformation, where they may likely see teams or silos within a large scale organization that have adopted new digital practices and ways of working. And they're looking to expand those ways of working to the rest of the business, but find that something that can work for a relatively small team, like a design system or a publishing approach may be difficult to scale out to the rest of the enterprise. And so our goal is to do consulting projects with clients to help them uncover what their pain points are, what the underlying problems are that they need to solve and then help them develop a vision and a roadmap for how they're going to get there.

Deane: (25:32)
When you do these projects, Karen, what is the end deliverable? And I both ask that in order to give you an opportunity to promote yourself. But I also ask that because the end deliverable that you provide, I've done consulting work with you. And I know that the end deliverable you provide is often some form of advice. And so what is the type of end deliverable that you're providing these people? And how do they normally go about acting on that?

Karen McGrane: (26:04)
So we like to start engagements with workshop. Back in the before times, it would be a full day workshop where we'd be on site and spend some time getting to know folks and presenting a point of view or some guidance to them. We have shifted that now. So we do remote half day sessions, so we usually do three session, and those can be staggered over the course of a week or two, or over three weeks or even longer. And the goal with that is for us to communicate some basic knowledge to the client, for us to learn a little bit more about the problem space. So in some cases that's all an organization needs and we will wrap up that workshop with just some high level recommendations. And that's it.

Karen McGrane: (26:57)
Other times that full day session then leads into a larger engagement or a series of larger engagements. Sometimes we'll set it up as a retainer with it. And we usually do that with a three month commitment. Other times we scope out a larger project with the traditional milestones and deliverables. We have a great workshop on content management and design systems that we've given to a handful of companies so far, if anybody's interested in the advice that Autogram can provide, we'd love to talk to folks about doing a workshop like that.

Karen McGrane: (27:33)
But to answer your question Deane, the end deliverable honestly, is usually some kind of report. I sometimes laugh as I'm writing up my SOWs, because I'm like, "It'll be a document, maybe a presentation, maybe both. There's probably going to be a spreadsheet in there too." But really it is the synthesis and the recommendations that we come up with that we're handing to the clients to say, "Okay, here's how you should approach is problem going forward. Whatever that problem might be. If it's thinking about how to structure their content or how to handle a migration process or how to integrate their design system with their publishing processes and the rest of the organization." We usually deliver a fairly robust set of recommendations to help them with their future implementation.

Deane: (28:30)
How capable do you think your clients are for acting on those? Put on your cynics hat for a minute, if a client doesn't take your advice, doesn't act on the results of your consulting engagement. Why did that happen? What's the biggest obstacle for them moving forward?

Karen McGrane: (28:50)
People probably are the biggest obstacle. I would say that most of the organizations we work with, we are talking at the intersection of many disparate silos. So we just wrapped up one plan engagement, where we were talking to folks from all walks of life, the publishing team, the CMS team, the brand team, the mobile team, people responsible for the apps. Just vast groups that all have their own little system or their own set of interests that they're bringing to the table. And as I'm sure you know in virtually all cases, there's not really alignment in what people think. The brand team has very specific ideas about what the design system should be. And those beliefs are not necessarily held by the content producers, content publishers that are using the design system to actually physically build the pages.

Karen McGrane: (30:01)
Those desires may not intersect with what the content management team or the actual development team is able to build. So getting that alignment or at least acknowledging here's our recommendation. And some of you are going to agree with it, and some of you are not. That's one barrier because then once we go away, it's in their hands. To some extent technical depth and just the limitations of what the development team can do is probably the other big barrier. I will say I talk to a number of clients where the desire to burn their design system to the ground and start from scratch is very real. They've invested a couple, three years of time in building something that has gotten out of alignment with the brand or what the rest of the organization needs. Lot of one off patchwork solutions have been put into place.

Karen McGrane: (31:06)
And the technical debt on the current system is so high that the temptation is to say, "Okay, we learned some things from this process. Let's start over." There're things that I would say we would consider as part of our strategic recommendations but I don't know that we would necessarily let something like technical debt define what our strategic recommendations are. Our goal is to help you get out of that technical debt. But we want to do is say, "This is how it should be not here's the best we think you can do given your current situation."

Deane: (31:53)
Do you do follow on engagements? Do you ever turn these over to the client? And say, "Okay, can you come back and help us do this?" Or is it, "Here's my advice and best of luck to you."

Karen McGrane: (32:05)
I definitely do not do anything.

Deane: (32:11)
Classic consultant.

Karen McGrane: (32:12)
I have a hard line in the sand where I'm like, we do not make websites. We may deliver something that uses HTML and lives in a browser, but we don't deliver anything that would ever be expected to actually go live on the public website or live through user consumption. I think that's a healthy line to draw. Man, building websites is a young person's game. I got to tell you.

Corey: (32:43)
It's hard and not very fun sometimes. Yeah.

Karen McGrane: (32:45)
No, it has to work at the end. That's the problem with it.

Deane: (32:49)
I always maintain that. I love talking about building websites-

Karen McGrane: (32:52)
Yes.

Deane: (32:52)
...and writing about building websites. And I love thinking about willing websites, but I do not like building websites.

Corey: (33:00)
And that's why Deane and I are doing podcasts now instead of-

Deane: (33:01)
Yeah that's why I moved over the product stuff.

Corey: (33:06)
Karen, I have one more question and it's a really important. In the book Web Project Guide at the start of the second chapter here, we have a little bit from the movie This is Spinal Tap. What is your favorite Christopher Guest movie, or any mockumentary?

Karen McGrane: (33:23)
Oh, it's got to be Best In Show, right?

Corey: (33:26)
Oh Karen, this is why you're the best. Best In Show is legitimately the best mockumentary. So, perfect.

Karen McGrane: (33:32)
[inaudible 00:33:32].

Corey: (33:32)
Deane do you have an answer that isn't best in show? Because if not-

Deane: (33:36)
I started watching best in the show and I bailed out when the Larry Miller character started making passes at the other guy's wife and it was just so cringe. I do not do awkward cringe humor well, I struggle with it deeply. And so that's why I could never watch Fleabag either. And so I bailed out a best in the show halfway through.

Corey: (33:55)
But you were also a dad to teenager, so awkward cringe humor should be like right in your [inaudible 00:34:03] house.

Deane: (34:03)
Yeah for them, they have to deal with my awkward cringe humor. Both my daughters are wildly sophisticated compared to me.

Corey: (34:10)
Yeah. That's going to be good. I think we've taken enough of your time Karen. I appreciate you talking with us and helping us kick this off over the first few months here.

Deane: (34:20)
Oh, no I have another-

Corey: (34:21)
[inaudible 00:34:21].

Deane: (34:21)
...wildly important question, Karen. After this interview, in the closing of this podcast, I am going to talk about how I don't know what Autogram means. So I'm going to step back in time now give you the opportunity to explain what Autogram means. So when I talk about it at the end of this podcast [inaudible 00:34:41] it'll make sense.

Karen McGrane: (34:43)
It'll make sense? So do you want to know What an Autogram is?

Deane: (34:47)
An Autogram, isn't it like a self-verifying sentence?

Karen McGrane: (34:49)
It is a self-referential sentence. So there's only a few of them in the English language that it takes the form of something like this sentence contains three A's, two BS, one C goes on from there. And the reason we like it, is that we think it's an apt metaphor for the type of work that we do, because the creation of an Autogram is something that you have to continually refine throughout the process. And you don't know if it is successful and until it is complete. You have to write the entire sentence before you can know if the Autogram is actually working. And we always thought that that was a great metaphor for how web projects work.

Deane: (35:34)
That is low-key brilliant. My hats off to you. I knew what it meant, but I didn't get the significance. But now that you explain that it's crystal clear, that is absolutely valid and true.

Corey: (35:43)
Karen was it you, Ethan or Jeff that came up with it first?

Karen McGrane: (35:46)
That was Jeff. Jeff Eaton.

Corey: (35:48)
Oh, Jeff.

Deane: (35:48)
Of course Jeff would, right. That's a Jeff thing.

Karen McGrane: (35:52)
That's a total Jeff thing. Yeah. We're trying to get the .com and the story behind the .com is that there's apparently this farmer in Georgia who has a lucrative side business buying up domains and then reselling them. So we've been trying to get Dwayne on the phone for a while to see if Dwayne will sell us the Autogram domain, but it hasn't happened so far. So anyway, Dwayne, if you're out there, call us.

Corey: (36:22)
Dwayne. If you're out there, how come you haven't bought the book yet? Awesome. Thanks Karen.

Karen McGrane: (36:27)
Thank you both. It's a pleasure to talk to you always.

Corey: (36:36)
All right. We're back from the interview. Karen's great. We love Karen.

Deane: (36:42)
Karen is great.

Corey: (36:43)
Yeah. Anything else you want to talk about on this topic, Deane? Or have we exhausted it?

Deane: (36:49)
Oh, I don't think we exhausted. We could talk about this forever and ever and ever. But this gets into the core of project management and project managers have a very hard job for a reason, because they're trying to juggle every single constraint and everything that is pelting them away from their budget, their feature set and their schedule. So if you are a project manager and you are staring down a project like this, ask yourself very hard questions about how hard your deadline is and where you can inflect. Where can you bend your project? Because I promise you is going to sound cynical. But after 15 years in services, I promise you, your project is going to bend somewhere.

Deane: (37:25)
Reminds me of, I had some edging installed some concrete edging and the concrete edging was extruded, it was like toothpaste. It was extruded in one unbroken line. And then they came through later with a big knife and they scored it in separate spots so that when it did break, because the ground moves as it freezes and stuff. It broke cleanly on those points. So they planned the brakes, they planned where it was going to flex. And so that's what you should do in your project, in the beginning as well. Plan where it's going to flex when things go wrong, where new flex your project, because I promise you're going to flex somewhere.

Corey: (38:02)
Great. Well that's our show. Thanks to our guest. Karen McGrane you can learn more about Karen and Autogram at their site autogram.is.

Deane: (38:15)
I feel like that's an unanswered question. Autogram is blank.

Corey: (38:20)
I think it might be the idea. Because then it's like autogram.is/whatever they want to say. So, hey marketing.

Deane: (38:28)
I know what an Autogram is. An Autogram, it's a self-verifying sentence or something. Okay. Hang on. We talked about before about how we're actually recording the interview with Karen after this. So you should ask Karen what Autogram means during the interview. Now everyone can know how wrong I am. Because I don't know what Autogram means.

Corey: (38:54)
Karen's also written two books for a book apart, you can pick up those two books, Content Strategy for Mobile and Going Responsive. You can pick them up@abookapart.com. The Web Project Guide is a project 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. The Web Project Guide is also a book. You can order the book @www.webproject.guide. If you are outside of the United States or Canada, we recommend ordering it on Amazon, where it is also available. It's large and it's in charge. And that's a thing I put into the script right now. And I'm sad, I did it.

Deane: (39:33)
Yes, that is awful.

Corey: (39:37)
Anyway, you'll love having a physical copy. But if you are not a book person, you can also read the full text online.

Deane: (39:43)
Let me rifle through it so people can see what they're in for. Here's what it sounds like to rifle through a Web Project Guide. That was delicious.

Corey: (39:55)
This is episode two of The Web Project Guide, which also corresponds with chapter two of the book, visit webproject.guide/scope-expectations for more resources on this topic. We've got to end this, but we'll be back next month with another episode. And until then go do amazing things.

Deane: (40:13)
Good luck.