{"id":9974,"date":"2020-01-11T15:29:45","date_gmt":"2020-01-11T20:29:45","guid":{"rendered":"https:\/\/wproadmaps.com\/?p=9974"},"modified":"2020-01-11T16:29:54","modified_gmt":"2020-01-11T21:29:54","slug":"can-we-talk-about-your-wordpress-project-requirements-definition","status":"publish","type":"post","link":"https:\/\/wproadmaps.com\/can-we-talk-about-your-wordpress-project-requirements-definition\/","title":{"rendered":"Can We Talk About Your WordPress Requirements Definition and Management Plan?"},"content":{"rendered":"\t\t
This is Episode 9 of our video series called \u201cCan We Talk About Your WordPress Projects?\u201d In this episode we’re going to talk about your requirements definition process<\/strong> and why you need to have that defined and in place.<\/p> Even though it was several weeks ago, in recent episodes of this series we\u2019ve been talking all about the essential processes that you need to have in place for your agency or your business, if you were in an individual provider. So far we talked about:<\/p> Today we’re going to talk about requirements definition or requirements management plan. The principle that this falls under most closely is Break the Job Down. And along those lines, the first thing you need to do is develop a method for positioning the deep dive (where you find out most of the requirements) either as the first phase of the project, or as a separate project. This is necessary so that you get paid for it and so you can incorporate changes over what you came up with after that hour-and-a-half pre-proposal meeting with the client.<\/p> If you position the deep dive as an activity where you PLAN to be collecting any new requirements, then that really sets the proper expectation with the client that we KNOW there’s going to be change.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t The way the 2-Step Proposal process works for me is that initially, I provide a range estimate in the proposal. Once that’s approved, then that first phase is all about the deep dive. And that’s where we actually do the full detailed website specification (Statement of Work). There are always things that are discovered during that process but because the client is right there with you as you’ve discovered these things along the way, there are no surprises.<\/p> Then we do a second estimate at the end of that first phase and if that estimate exceeds what was in the initial proposal, then the client has the option to cancel. They hardly ever do, though, because they’re right there with you as you go through this process. The other<\/u> thing it does is that it also gives you an exit strategy. For example, if the client is just too difficult to work, with this method, your just hand over that Statement of Work that they’ve already paid for, and kindly suggest they get someone else to build it. So that\u2019s how you can avoid estimating for things you don’t yet know.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t The next thing is to break the deep dive discovery into smaller little chunks and deliverables. The way I do this starts during the proposal phase. After we do that first initial meeting and we get the basic requirements, I create a visual site map<\/strong> and get the client\u2019s approval on it. That’s what I used to determine how many pages there are going to be that I use for the initial proposal estimate.<\/p> Then, after the proposal is approved I break it down like this:<\/p> Layout\/Wireframes<\/strong> \u2013 these are totally black and white with no design just so we know all the \u201ccontainers\u201d where the content is going to go. You need to know that in order to estimate how content is needed and what the content-related activities are.<\/p> Content Specification <\/strong>\u2013 I use the wireframes to develop a rough order of magnitude so that I can more precisely estimate how long the content activities should take.<\/p> Functional Requirements <\/strong>\u2013 how the website will operate, what functions will it perform?<\/p> Technical Approach <\/strong>– sometimes this is pretty high level and other times the technical design is a lot more detailed especially for clients that are more technically oriented and want to know more detail about the infrastructure of what your building for them.<\/p> Branding and Design<\/strong> \u2013 we save the design and branding for the end part because ALL of the other things I\u2019ve mentioned have an impact on the design. So why would you go ahead and do a design and then just have to make changes to it when the client wants to change the layout or the functions or the content? And if you don’t do all of those things first you\u2019ve just created re-work for yourself on the design.<\/p> You may choose to break yours down differently, but it’s important to break it down into logical chunks.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t The requirements definition plan is very closely tied to your acceptance management plan because when you tell your client how you’re breaking the website spec down, and which deliverables on which you\u2019re going to input and approval, then you talk about the acceptance management plan at the same time.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\tThe Requirements Definition Process<\/h1>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
The 2-Step Proposal Process<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Breaking Down the WordPress Website Spec<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
Elements of a Good Requirements Definition Plan<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
How to Learn More<\/h2>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t