Can We Talk About Your WordPress Requirements Definition and Management Plan?
This is Episode 9 of our video series called “Can We Talk About Your WordPress Projects?” In this episode we’re going to talk about your requirements definition process and why you need to have that defined and in place.
Even though it was several weeks ago, in recent episodes of this series we’ve 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:
- Acceptance Management
- Client Management
- Issues and Risk Management
- Change Management
- Your Estimating Process
- Communication Management
The Requirements Definition Process
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.
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.
The 2-Step Proposal Process
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.
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 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’s how you can avoid estimating for things you don’t yet know.
Breaking Down the WordPress Website Spec
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 and get the client’s 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.
Then, after the proposal is approved I break it down like this:
Layout/Wireframes – these are totally black and white with no design just so we know all the “containers” 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.
Content Specification – 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.
Functional Requirements – how the website will operate, what functions will it perform?
Technical Approach – 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.
Branding and Design – we save the design and branding for the end part because ALL of the other things I’ve 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’ve just created re-work for yourself on the design.
You may choose to break yours down differently, but it’s important to break it down into logical chunks.
Elements of a Good Requirements Definition Plan
- Defines the terms business requirements, functional requirements, and technical requirements.
- Describes the process for determining the business requirements
- Describes how the functional requirements are derived from the business requirements
- Describes how the technical requirements are derived
- Define how the process actually works (step-by-step) including the “chunks” that it will be broken down into.
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’re going to input and approval, then you talk about the acceptance management plan at the same time.
How to Learn More
Join the WP Project Manager’s Academy – a FREE membership program where you can learn everything you need to know to consistently get your projects completed on time, within budget, with features that meet the client’s business requirements.
Next Time…
In the next episode we’re going to talk about the importance of setting up some standard assets as part of your Technical Approach and what you need to tell (and not tell) the client about that.
So until then, as always, stay strong, stay productive. And I’ll see you soon.