 So this talk is on how to stop scope creep once and for all. Do you like my little Wapoo? Y'all, that came from Wapoo.us. Are you aware of this place? I didn't know about this website. They have Wapoo's for everything. And some of the word camps even get them to do one for their mascot for there. But this is the scope creep Wapoo. And they classify him as a villain. Does anybody else feel that scope creep is evil? Right, of course. It's the bane of our existence, is it not? Well, I'm going to show you. I'm going to give you the secret sauce on how to stop scope creep once and for all. So a little bit about me. My name is Beth Livingston. I have my business's WP Road Maps and my website's WPRoadMaps.com. And there's my email address. I started out as a business analyst in corporate IT. And that's where I cut my teeth on this whole concept of the six principles of productivity management, which I'm going to tell you about. In 2013, I had an idea to develop a web app for grocery savings. And I presented it at start-up weekend the first time it was ever held in the Triad of North Carolina. And we won third place. And it was great. And then I worked on that for about three years. And when I got ready to launch it, the economy had improved so much that it was kind of obsolete. So I had built a number of WordPress websites in the process. And so that's when I became a WordPress coach. And I've been helping small businesses basically increase their productivity by use of web technology and process, and mostly by helping them build effective websites. Recently, I did a slight pivot in that I have really been seeing a need among WordPress practitioners for how to stop scope creep, how to do project management. I know that a lot, it appears to me after going to many WordCamps that there are a lot of agencies who have a great creative and a great development team, but they don't really have anybody that has that project management knowledge. So I'm in the process of developing some online courses that will be available on my website. But that's a few months down the road. So what you're going to learn during this presentation is what are the six principles of productivity management? How can those six principles help stop scope creep? Which of those two principles are the most critical in stopping scope creep? And then how to apply those two principles to a WordPress project? So what are the six principles? The six principles are really just common sense methods for getting your jobs done on time and within budget. And we all know that we're supposed to do these things, but sometimes we lose track of them when we're actually pulling off a project. This can equally be applied to whether you are tiling your kitchen floor or doing a project at church or a website project. The six principles are kind of universal in that way. And where did they come from? Well, believe it or not, they did come from corporate America. Yes, we all believe now that corporate America is evil. However, there are some good things that come out of there. And this was one of them. I once upon a time worked for a company called Keen based out of Boston, Massachusetts. And the founder of that company wrote a book called The Six Principles of Productivity Management. And it honestly changed my life. And one of these days I'm going to write a book about that. And it's important to remember as we talk about these six principles, that this is not project management. You should have a project management methodology. This is productivity management that kind of sits on top of or runs through your project management methodology, whichever methodology you're using, whether you're using an agile methodology or using a waterfall, whatever you're using for your software development and your project management, this should run all the way through it. So here are the principles. Keen's six principles are on the left. And on the right, I have modified them slightly to apply to WordPress. And that is to find the job in detail. We know we're supposed to do this, right? But if you define that job in detail with WordPress, you also need to start with a content-first approach. How many people find that it takes forever to get all the content from the client? Right. Well, if you refuse to start until they give you all the content, chances are you're going to get more of it, if not all of it, before you start. Because honestly, how long does it take to actually build a website, y'all? Not that long. What takes a long time is getting all that stuff together from the client. So if you just concentrate on doing that before you write the first line of code or create the first page, it will help in stopping scope creep. Because how many times do, as soon as they start to gather that content, oh, and I forgot that, right? Because they pulled some content and went, oh, yeah, we need this on there, too. So if you do all that first, then you get that defined up front. Get the right people involved was the first principle. But in WordPress, you not only need to get the right people involved, but you need to get the right plugins involved. Am I right? Okay, as you're looking at these, try to figure out what you think are the two most important ones, okay? And then later on, we'll talk about what they are. Okay, then we've got to estimate the time and cost. That's for every project, no matter what. There's no difference. Break the job down, which I'm going to talk about in a minute, what that actually means. Establish a change procedure. That's really good. You establish that change procedure up front, you tell the client what it is, and then when the client wants to make a change, what do you say? Well, I'll just throw that in. That's going to be easy. It's going to take me five minutes. I'll just throw that in. Then what does the client want the next time? Just throw that in. It can't be that hard, right? So that's how that scope creep starts, right? So you have to take a really strong attitude about it and just stick to it. So that's why my fifth principle for WordPress is not only establish that change procedure, but you have to stick to it. And then establish acceptance criteria. And I've changed it that not only do you have to establish acceptance criteria for how do we know we're done, how many times have you thought you were done and the client said, were you not done? We still have, right? Because they forgot. Or they thought they had told you something. So it's very important to have that written down at the beginning as well. Now, I'm going to stop here for one second and I'm going to read you the forward of a book called Cultural Calamity. It was written by Joe Mayo. He is an internationally known project manager and risk manager. And he was a colleague of mine when I worked at Keen. But this kind of describes this whole... Look, this is kind of like a cult. It was for us when we worked there because you had to follow this. It was our credo. So let me read you this real quick as soon as I bring it up here on my phone. The culture endured for decades and was unfazed by market conditions, massive growth through acquisitions and numerous technology evolutions. The heart and soul of the culture was very simple and was centered on a book written by the founder and his wife called The Six Principles of Productivity Management. Productivity management was written in response to a significant number of project failures that occurred in the 1970s. The founder commissioned a study of these project failures by an independent institution to understand what went wrong. The study identified six causes that the failed projects had in common, which gave birth to the book. There was nothing magical about the six principles. They were mostly common sense, but they described the founder's philosophy about how people should be treated and set forth a common approach for conducting business. Productivity management wasn't a tome. It was less than 200 pages, but it described basic concepts that applied to any type of work. What was different is that everyone in the entire company embodied the six principles and lived by them every day. Anyone who joined Keen was given a hardbound copy of Productivity Management on his first day and they were required to attend formal Productivity Management training within 90 days of joining the company. It didn't matter if you were an administrative assistant or vice president, you got the book. You read the book, you took the training. As a quality assurance manager, I attended all executive management reviews in my region. At one particular review, there were some new managers and a new vice president. After introductions, the senior vice president asked the new managers and the vice president when they were scheduled for Productivity Management training. The new vice president said, I've been in this business over 30 years and I'm pretty sure there's nothing in that class that I don't already know. The senior vice president's response was swift and decisive. He said, if you want to work here, you better complete that training before your next review. The new vice president didn't complete the training and was gone shortly thereafter. What is important about this is that everyone across the global enterprise knew the six principles and how to apply them. Keen had operations in the US, Canada, UK and India. It was possible to walk into any project and be productive almost immediately because everyone followed the same core principles and used the same terminology. So that's why this is so powerful. If you can use it consistently, it really does work. The principles are based on the idea that a plan is just a plan. I think we get caught up into what we've given in the estimate, we've given in the project plan. Now that's carved in granite. If you set that expectation at the beginning, then you're going to have trouble. But if you set the expectation of, look, this is just a plan. It's more like a GPS and less like a road map. Because you're going to run into something or you're going to take a wrong turn and it's going to say rerouting. You have to do that throughout the course of the project. So I'm just going to read this statement off the slide. Instead, we should head out on our journey with a well thought out and well defined plan understanding that discoveries made along the way may change the route taken as well as the final destination. And this is one of my favorite sayings from Abraham Lincoln. If you give me six hours to chop down a tree, I'm going to spend the first four sharpening the axe. And that's the other premise, as I said before. It doesn't take long to build the website. It takes a long time to design the website and figure out how it's going to look. And everything, everything needs to be in writing. It doesn't get you into trouble every time. So I mean everybody's heard this. You've seen it probably in people's cubes, right? If it isn't in writing, it didn't happen. But you really have to take that attitude. Excuse me. I was saying earlier, I do musical theater sometimes. And I am never nervous because I'm pretending to be somebody else. But when you're up here doing your own thing, it's a little different. I'm getting the dry mouth. So how do these six principles help stop the scope creep? This part kind of quick because we're going to delve down into the two that are the most important and talk about those in a little more detail. Okay, so the first, and keep thinking about which two you think are the most important. Okay, so the first one is to find the job in detail with a content first approach. So if you use a drill down method, and what I do in my proposals is I never give, this is another one of the principles, it's like a sub-principle, is to avoid early precise estimates. Because I always give a range of cost and a range of time. And if they agree to that, that becomes the contract. But then we drill down later into that detailed statement of work. When we do the detailed statement of work, then when you re-estimate if you've gone outside of that range, I give the client the option to back out. Now, nine times out of ten they don't because we've already set the expectation that we're going to do our best to discover everything on the front end, but we're going to acknowledge up front that we're probably not going to get it right. The second step is get the right people and plugins involved. So, there's always a set of roles that get fulfilled on every website project, right? You've got a project manager, you've got a developer, you've got a designer, and you may be doing all of those roles, but they're still separate roles. They're separate people to be separate roles. So what I do is I have a standard list of roles and responsibilities that I have in my proposal template, and I go through that, I modify it for each client. And I also have the roles that the client's going to fulfill and what those responsibilities are so that they can see that this is not just handed over to me and I'll take care of it. We're going to be both involved in this process. The same thing with a set of technical everybody's got their favorite technical plugins, right? You've got your favorite image compression plugin, you've got your favorite page caching plugin, we all do. So I have my list of technical plugins already decided and then I modify that based on the needs of the specific client. And then I do the same thing with business function plugins like e-commerce. I mean, is there more than one? I'm just wondering. Everybody uses e-commerce. I actually have a site that I use a different one on, for each project. Then the next principle is estimate the time and cost and I alluded to this earlier that you don't just estimate once, you estimate early and you estimate often. And these are all the different times that you could estimate. Now I am going to switch over to my notes slide for just one second because I want to read you another little statement that is very telling about estimating the cost. So if y'all will bear with me in looking at my notes page. Just one second. For years, project managers have searched in vain for the key to accurate estimating. We have combed ancient scriptures prayed to divinities and scaled treacherous ice-covered mountains to consult cave-dwelling sages. Somewhere out there must lurk the perfect algorithm that once fed a few discrete variables gives the absolute accurate cost of a proposed project. Alas, we never found the algorithm but we have gained enlightenment. There is, there is no key. And it's sad but it's true that with estimating, it's kind of a trial and error thing. You get better over time at estimating. One of the things that is fair, well we'll get to that when we talk about change. Okay, breaking the job down. How many people are familiar with the agile method of development? Anybody? Okay. Those of us who've been around for a while know that all of those methodologies are the same stuff. They're just organized different with different names around it. John Keane actually came up with the sprint long before anybody else did and he called it the 80-hour rule. And he required us to have a deliverable every 80 hours. It wasn't necessarily always a client deliverable but there was a deliverable every 80 hours because that, man, hours not just two weeks. And that way we always knew where we were within two weeks, within 80 hours. You knew, I'm either this far behind or I'm this far ahead. So that's why it's important to have those breaking the job down into small little chunks and doing an assessment as soon as, you know, every time you deliver one of those or do a sprint. It's the same thing. Establish and stick to a change procedure. Okay, so this should be in your proposal, it should be in your statement of work and it should be something that you go over in great detail with the client and you tell them just acknowledge the change up front. Acknowledge that we know we're going to miss some things, you're going to forget about some things. So here's what we're going to do. Remember that estimate we gave you? We're going to take 30% of that total and we're going to put it over here in this change bucket. So that estimate we gave you has now increased by 30% but we're only going to use that change bucket if there's a change. That's how you always get your projects done within budget. Just acknowledge the change and set a chunk of money over there for it and then that way you're always... I won't say always. If you were really bad at defining the job up front then probably you might go over your change budget but if you're really good at it up front then you can get it done. You can set that amount so that chances are you aren't going to use the whole thing. You might use some of it but you won't use it all. So acknowledge and actively manage that change throughout the project and make sure the client... you set that expectation with the client. This is a hard and fast rule. It's the way we do it and we don't do it any other way. And then there's establishing the interim and acceptance criteria for the end and that's another mistake we often make because we think, we just know when, I mean it's there. Everything's there, it's done. There's those specific acceptance criteria that are measurable so you'll know that you are done and so the client will know you're done. Okay, so I'm going to go back up to our slide with the six on the left and six on the right. Hold on, I'll get there in a minute. Okay. So which two do you think are the most important? Oh come on, this is an interactive thing. Change procedure of course and then what's the other one? Right. Define the job in detail and establish and stick to the change procedure. Define the job in detail with a content first approach and then establish that interim and then establish the change procedure. Okay. But what's really interesting is that most of those others are also part of defining the job in detail. Okay, because to define the job in detail you have to establish that acceptance criteria. You have to get the right people and plugins involved. That's another task of defining that job in extreme detail. Breaking the job down estimating the time and estimating the time and costs. So how do we apply this to most critical principles? Well this is how I do it. I start with a proposal questionnaire and I've actually in addition to the slides on my website I've also included this proposal questionnaire. You're welcome. Hopefully you'll find it useful. It's just what I use to do that first high level discussion with the client to get so I can at least give them an estimate for approval. Then I have the proposal. I also put my proposal template on my website that you can look at too. So then I take that questionnaire and I fill in the proposal. I walk through that with the client. We make any changes to it based on that walk through and then we move to the next step which is the project definition questionnaire and it just has more specific questions, more details. How many people have ever taken the WP elevation training? Anybody? Okay, so you know how Troy talks about going wide and deep? That same kind of process where you're saying and I heard you talking about it earlier where you go, why do you want this? Right? This is another piece that I think we forget to do all the time. We don't. Some people forget to do is you start talking about what should the website look like? What pages should it have? But you have not even discussed with the client what are your business objectives? What are your business requirements? What is this website supposed to accomplish for your business? I don't care what it's going to look like. I don't care what kind of function it's going to have. Tell me how it's going to help your business. And by that having that discussion and not even talking about it like it's a brochure, not even like it's a website that the client always wants to start designing on day one. And so you got to stop them from that and really get down and understand what their business requirements are. That's a big part of defining that job in detail. And you'd be amazed, about how he was asking why do you need a website? Why do you need an updated website? And the guy was kind of him and hauling and saying he needed it for this. I just need more traffic and I need more this and I need more that. And Troy's thing is you just keep asking why. Why? Why? And finally he got down to the guy was going to sell the business. That's a business requirement that changed his whole approach because it makes a client really annoyed or uncomfortable but you have to do it because it's the only way to find out and define that job in detail and find out what those business requirements are. Then I create a statement of work which is a lot of the proposal is repeated in the statement of work but you get down and dirty into some really detailed ways, detailed sections of how you're going to do business and detailed sections about what are your business requirements. Then again you have that walk through with the client and make sure that you got it right and then again it's very revealing you'll learn a whole lot more by doing that walk through with the client. Then there's the work breakdown structure which is basically how many people actually have a project plan and use it when they develop a website? Are you kidding me? Make an Excel spreadsheet it really helps. What I did was I have a standard one that I use for every client and then I just modify it based on like if they're not going to have e-commerce I take out all that stuff if they're not going to have this or that I take those things out or I add things in. That's just basically a list of your activities and your tasks and then I use a set of content gathering forms that I created that I just hand them to the client and then you get this back to me is when we will start your project. If you take six weeks to get this back now we did an estimate based on we were going to start on this day and we'll start on this day if you get me all this content. Are you going to get all the content? Probably not but if you take that attitude that we're not starting until you give it to us you'll get most of it. You can also, let's say it's an updated website that you're doing from the other site but you still don't start building the site until they validate those content forms that this is exactly what they want on there because then when you go to develop the website and you get it done in like no time you're a rockstar in their opinion right? If it's dragging out and dragging out because they're not giving you the content they don't see themselves as the problem they see you as the problem so just take that out of the equation so this is kind of how the process how the project definition process works. You start with that proposal questionnaire that feeds into the proposal the proposal feeds into the statement of work but your project definition questionnaire also feeds into the statement of work and then all those other principles well the work breakdown structure and then all those other principles the roles and responsibility the time and cost estimates the change management procedure the acceptance procedure and criteria is all there in that statement of work they agreed to do the project if it came in in that range from the proposal that range of time and that range of cost and this is to validate let's look at it this way the proposal is what we're going to do and the statement of work is how we're going to do it. Does that make sense? You can call it whatever you can call that statement of work something else but that's what we used to call it back in the software development days. So you can't really see that sample from my proposal questionnaire so you can I'll give you the website link in a minute but excuse me I need another drink of water so you can get the proposal template but basically it's talking it's asking questions like is this an existing website what are the purposes and goals for the website who's going to host it do you already have a domain name all those questions you have to ask how many people use a checklist or something like this when they're talking to the client? Right, I mean if you try to do it from scratch every time you're going to forget something so that's why it's important to have this thing that you follow every time what kind of text and graphics are you going to need that sort of thing so these are the sections that I concluded my proposal basically what is the project request and snapshot what's the background and the business requirements and this at this point in the proposal really high level you might have two or three business requirements right I want to drive more traffic more customers to come into the shop you know whatever those business requirements are then there's your scope how many people define a scope for their clients really need to do that because you got it and the end scope stuff is not the issue it's the out of scope stuff so in that scope section you need to include what's in scope and also a very detailed list of what is out of scope if you're not going to be building content you need to make sure you write that down for your client because a lot of times they just make the assumption that you're going to do the content too then here's your proposed solution and deliverables you know we're going to do a website here's the plugins we're going to use so you put down what your solution is at a high level time and cost estimates arrange it will fall between this and this change management acceptance management I always include a section for frequently asked questions because I get tired of answering the same questions over and over like who's going to manage the website whereas you know what do I do when I have a problem after you do this website do I call you who do I call put all those things down in the proposal and then what are the next steps you know put in the proposal tell the client exactly what they need to do to accept that proposal go to my website click on this link pay me some money and then we'll get started and then I move to the more detailed project definition questionnaire which includes things like in this example who's going to approve these things who's the approver for each one of these deliverables that's just one section the other sections did I tell no I didn't put them in here did I include this on my website for you guys no I just did the proposal questionnaire and the proposal these will be ready at a future date but so it's that kind of detail now you're putting in the specific names of the people from the client you're putting in specifically who's going to do what and I'm getting a lot more specific about that okay so then in that statement of work these are the sections that I typically include in a statement of work your project identification which basically just copy that over from the proposal because you already did that part your scope of effort now while you were going through this second questionnaire you've gotten a lot more detail so now your scope you're going to take that scope that you had in the proposal and you're going to define that in a lot more detail are y'all getting tired of all this detail the customer does too but it is so important because if you do all of this up front building the website takes no time at all oh and it's really important in that scope section to put what's in scope that you're going to do what's in scope that the client is going to do and then what's out of scope because sometimes they don't realize that they have to approve stuff they have to test stuff to user acceptance testing they don't realize that they have this time involvement so you need to let them know up front because then they're going to be more likely to make the time in their schedule put that on their list of things they need to do your management approach who are the required management resources what is your process for communication we all just make these assumptions that well we'll just call them if we need to talk to them or they'll just call us if we need to well who are you going to talk to at the client if it's a really small client and there's two people it's not too hard you were talking about pretty large projects if you've got a large project with a large team you need to really clearly define these things like how is this communication going to happen who do I escalate to if I get in a problem with my subject matter expert who can pass who do I escalate that to it's really important to define all of that and of course your team roles and responsibilities and then your technical approach that's the details you know hosting the environment you're going to have a staging environment and then move it over and your work approach what your deliverables are what your technical plugins are your development approach your time and cost your proposal and then you give them examples in your appendix of all of the stuff that they're going to need to use during this project your change request form your acceptance forms and see if you do all this you look so professional that's a good thing and then like I always include in the appendix also what my website care plans are if that's something that they are interested in and I use that kind of as like the opportunity to sell them on those website care plans but I don't generally make that part of the proposal I make it as something they need to think about adding on to and here's an example of the first couple of sections of my work breakdown structure and you see I just use an excel spreadsheet but boy does it help you to not forget stuff and to stay on track and if you break the job down so that in this work breakdown structure you have a deliverable every 80 hours then you will always know if you're doing things on time if you're getting things done early late or on time and this is an example of a couple of my content gathering forms that I use the one on the left is for page content so you've got your title the slug, the page type what kind of content is it what are the SEO keywords what are the images are we using a featured image is a plugin required for this page to do something it doesn't need to have a sidebar those sorts of things now are all of those going to get filled in by the client on day one no but if they don't know what to fill in then when you go over them with the client you can fill those things you can gather from them what they are and you can fill them for testimonials okay so how do we establish and stick to a change procedure this is a change procedure we used to use it keen I still use it today I've left it in as I copied it from my template so it's got a spot to put in you know your client's name your business name that sort of thing so basically it reads like this anybody can request a change the change goes the change request of course there's a form for the change request that goes to the project manager the project manager now remember that project manager might not be designated as project manager especially if you're a solopreneur and you're doing your own thing just by yourself you are the project manager you analyze that change request complete the form with the estimates on it then you log that change request especially if you anticipate there's going to be quite a few of them and then if you have regular weekly status meetings which I highly recommend well depending on the length of the project if the project's three weeks long I don't know about having one every week but basically you report on those changes in the status meetings as well the project manager presents the change request to whoever's responsible for approving them now let me say something about change too change can be a change to the timeline can be a change to the cost it can be a change to the resources which doesn't affect time or cost it can just be a change that has no impact but if you don't document that change then you don't remember to go back and test it because you're looking at your original set of requirements so the other thing that the change request process does is it keeps you on track for making sure that you've got everything that you agreed to and then to make sure you test everything so you give that to the client representative who's responsible for approval and they can approve or deny it in writing and you give them a time frame this needs to come back to me within three days because often times you'll give them the change and then it takes a couple weeks to get the thing back they don't understand that now we've got to change everything again because it took you so long to get that back to me so I usually use three to five days as my time frame and then you make it clear that if the client doesn't respond in that time frame that it'll be added as an item on the issues log so it becomes if it's a change, if they don't respond that becomes an issue and then the project manager maintains those change control documents along with all the other project documentation and then number seven this is the big one this is what you need to make sure your client knows on day one that no work associated with the change request will begin until formal approval is received when a change is approved the project plan will be adjusted the amount authorized will be subtracted from the change budget and added into the project budget and so I said see time and cost section for more information on the change budget but we talked about that so the other thing that you need to also establish is what is your criteria for change because what that means to you and what that means to the client to totally different things so it's important that you all agree on what is that criteria and basically the ones that I use are that any change to the statement of work I don't care what it is any change to the statement of work is a change could be the personnel it could be a contradiction to information that you had in there that's wrong changes to an accepted deliverable to things like the system went down for summary the clients you're working on the working on the client's site and their system goes down and so you lose a day that's a change if it's going to impact your schedule that's a change so in summary how do you stop scope creep once and for all those six principles of John Keane's all contribute to stopping scope creep I changed them a little bit to apply to wordpress because that's my jam and what I do the two most critical principles are define the job in detail and establish and stick to a change procedure at WP road maps we use six tools to define the job in detail in a drill down approach and that is the project the proposal questionnaire the proposal the project definition questionnaire the statement of work work breakdown structure and those content gathering forms and if you don't build a single page until you have all of those things done then you'll be able to get that website built a whole lot faster and you'll you know what the other part is you end up getting it done closer to what your client envisioned than if you didn't follow these this sort of drill down procedure you know what here's what's funny everybody thinks that quote is the devil's in the details if you go to Bartlett's book of quotations you know that big fat book's got all quotations in every that's not the quote the quote is God is in the details and somebody changed it at some point and everybody's picked up on that one because it's excruciating getting into that detail and talking about it and trying to get it out of the client is very painful but it is so worth it so your change control process should be outlined in the project definition documents and reviewed with the client so you're setting that expectation up front we know it's going to change we know it's going to change and here's our criteria for that so the end