Create a Project Plan
Determine the true time scope of your project. When does it start (hint: right now, perhaps) and how will you choose someone to help through to the very end?
Does this Apply?
You need a plan. Full stop. Don’t do anything else without having a plan for how it will work out. Either do it yourself or hire someone to help you put it together. But don’t think about a web project without a web project plan: you will simply waste money and time.
When you think of a plan, what do you think of?
Do you think of a consecutive series of steps, with one happening after the other, like the steps you’d take to build a table or install a thermostat?
Or do you think of a plan as a set of expectations, with the pathways leading to those expectations open to interpretation, like a maze with multiple correct answers?
For a web project, planning is often going to land someplace in the middle. We like to compare a web project to a building, where user requirements – the scope of the building – turn into a blueprint, which helps plan several concurrent areas of expertise. It’s just that instead of electrical wiring, and framing, and interior design, we’re looking at server setup, content management implementation, and content migration.
Because web projects are often managed by a marketing or communications department and closely tied to communication goals, we often encounter the assumption that a web project should be planned in the same way as an advertising campaign: a creative burst worked under mysterious methods, then a grand reveal. Ta-da! it’s done, now someone make it a site!
While some of this methodology might work, the truth is that there are a lot more moving parts when it comes to a web project. The web is complicated, which means planning for the web is complicated. Doing some kind of hand wave over “the development part” is going to lead to a doomed project.
Of course, this being a process that involves industries that sometimes seem to work at odds with each other, there’s more than one kind of planning involved with a web project. Typically, two plans move along concurrently:
The strategic plan, which determines the things you’ll need to create a usable site that meets your business goals.
The operational plan, which determines the people and external teams you’ll need to pull together to make the strategic plan work.
The Strategic Project Plan
If the idea of a strategic project plan seems vague, it’s because it’s one of the ultimate “it depends” documents. It’s unique to the project itself – it cannot be created full cloth from a template, and instead pulls from a variety of different sources, whether it be your marketing department, your IT department, or some kind of stakeholder survey.
For us, the strategic project plan is, in essence, an actionable path. It says “this is what we’re going to do” in a way that defines the steps. If the project charter is the intent to travel, and the project scope is selecting a final destination, the project plan is your Google Map. It’s not a step-by-step documentation of every task and ticket – just as your travel plan doesn’t include every rest stop and emergency Wall Drug doughnut stop. 1 Instead, it’s a road map that we can work through in order to reach our goals.
A strategic project plan may include any of the following 2 , depending on your project needs:
Reiteration of the purpose and expectations for the website, sometimes even including enough history to help identify and explain the initial spark
Reiteration of project scope
Project requirements, both explicit (as in, we need this specific functionality and integration) and open for interpretation (as in, we need a solution to a specific problem)
Expected deliverables and documentation
Project timeline for both major stages and specific deliverables
Project discovery content, such as competitive or contemporary analysis, content inventory and audit, branding and messaging requirements, or other business strategy documentation
Much like the project scope, the project plan needs to communicate just enough to breeze away any risk of miscommunication, which means the more layers of project resources – from interdepartmental to external agencies – the more project planning is necessary. High level purpose and expectations can be important if the team is disconnected from the initial spark, while team assignments might be completely unnecessary for a small internal team.
In fact, the strategic web plan can include almost anything related to the final project. It’s open to interpretation, and it will largely depend on what you need. Instead, it might be easier to tell you what is not part of a strategic web plan:
Business planning: While business needs and pain points often surface during the discovery and testing phases of a web project, the web project is not necessarily the time to start trying to figure out who you are and what you want to be when you grow up.
Marketing planning: The website is an important part of your marketing plan, and coordination between your branding and web design is crucial ... but we advise against using your website as the testing ground for a full brand refresh, unless the new site coincides with an existing design study.
Not that these aren’t important or complementary – in fact, mention of how a web project fits into business and marketing planning is important – it’s just that trying to shove every possible business fix into a single web project is going to throw the project off and cause delays. The more things you’re trying to change, the more you’ll have to plan and the longer you’ll have to wait.
The Operational Plan
And then, there’s the idea of operational planning. You have a general idea of what you want to do, but now you need to determine:
A staffing outlook, including who will work on the project and whether or not external resources are necessary.
A formal capacity timeline, where the project is listed in phases and real dates and deadlines are assigned.
In essence, who is going to work on it, and when will they do it? While the strategic project plan is more focused on what is happening, the operational plan is the purview of your project management team.
We discussed the concept of building a team in the last chapter, but beyond this you will need to know what to expect when reaching out for help. Let’s talk quickly about proposals.
The Request For Proposal
Now that you know the strengths of your internal team and understand where there are holes, you may realize you can only do so much on your own.
Which means it’s time to create a plan of action for hiring some new friends, in some sense. It’s time to begin thinking about the request for proposal.
First, know this: you don’t need to do a formal request for proposal ... unless you need to. If you’re funded in part by any kind of public money – either through the government or through a foundation or grant – you may be required to submit a formal request for proposal. It will be long, and it will include things you don’t need, but it’s all mandatory.
Second, know this: a request for proposal can be incredibly effective in helping you choose between two firms that you have your eye on, or to better understand the landscape of firms. It’s great if you don’t already have an existing relationship.
But, if you know and trust a firm and you want them to work for you ... just hire them. Refer back to the first point: You don’t always need a formal request for proposal.
What’s In A Proposal
Knowing what to put into a proposal can be overwhelming. There’s a good chance you have no idea what to ask for, let alone who to send it to.
There’s a balance between asking too much and not asking enough. You could pack your proposal request with a ton of questions – dozens of pages worth! – and get back a lot of great answers ... but you may also disqualify someone based on a non-crucial factor, one that could be avoided through simple conversation. On the other hand, asking for too little in a request might flood your inbox with horrible fits.
Like with any kind of survey, a request for proposal is best at pre-qualifying firms – both positively (where your questions help pre-select firms that work best with your process) and negatively (where your questions help repel firms that simply will not do). They help you determine a level of professionalism and competency ... or, at least, as much competency as a firm is willing to let on. 3
So how do you do this? We have some tips: 4
Do not send your RFP to everyone. Understand that the amount of effort a firm will put into your response depends on either how much work they have right now, or how good the odds are that they’ll win the project. This means that:
Bad firms who need the work will respond to anything.
Good firms will see that a bunch of firms have received the RFP and won’t choose to respond, knowing the odds of them getting it are too thin.
This is where pre-qualifying comes in. Look for firms that work in your vertical, ask for referrals, or seek out thought leaders in the industry. Usually making a quick phone call to ask a few quick questions will disqualify a bunch of different firms.
Write Stories, Not Requirements
Follow the sage words of Kas Thomas: ask for a narrative response that tackles process, rather than a giant list of requirements.
Sure, you might need to know some functional details and want to see a bullet list or two, but ultimately you’re looking for someone who understands what you’re doing and why you want it to happen – having them relay their version of the story, alongside their proposed plan, will be invaluable.
Remember: the audience for an RFP isn’t just the vendors you’re trying to attract. The work you do in writing an RFP will pay off in helping you better understand what you want, what is possible, and what is beyond your wildest dreams. It’s easy to write down a feature during a planning meeting, but it’s another to ask a vendor to spend time scoping and placing a timeline on something you know isn’t completely necessary.
Be Honest About Your Budget
We know: the unspoken rule of agency life is that you never let anyone on to how much money you have. But in a case like this, a good firm is going to take your budget and be honest with you about how much can be done. It will also eliminate firms that are non-starters, both those who will not take on small projects and those who are too small to take on gigantic projects.
Every web project, no matter the phase, requires an organization to budget for three separate things:
Monetary: How much will this project cost in actual currency. This is the most obvious.
Time: How much time will this project take up? For some organizations, time is the same as money – the 20 hours a week that your internal content strategist spends on a project is 20 hours you’ve paid them to do that work instead of their day-to-day work.
Attention or Priority: While not directly tied to money, the amount of attention or priority a project gets ties directly into how successful it will be. Attention and priority often dictate both time and money.
As an organization, you ultimately need all three. You need funding for the project, you need someone who can work on the project, and you need leadership to give a high enough priority for the project that it doesn’t fall into the cracks every time some other project sprouts up.
Also, when you’re being honest about your budget, also be honest about yourself. Know your expectations, and know your limitations. Give realistic and honest timelines for when you’ll get back to vendors, and be clear about when you’ll need help beyond simple feature development.
So, how long does a website take to build? You might as well ask how long it takes the average person to get home – it depends on so many factors (in this case, your distance from home, whether or not you’re at work or on a vacation, whether or not you’re walking or driving or flying, and even the definition of “home” itself) that the answer is rendered either impossible to determine or irrelevant.
What it comes down to is this: if you need a website by a certain time, your implementation partners and web team will let you know if that’s possible or not. It’s not as easy as saying, “this takes 140 hours to build, so we can have it in 3.5 weeks (at 40 hours a week).” There’s so much more that goes into it than the raw hours necessary to implement design and write documentation.
For example, we often forget about how organizational and management time works, and how it needs to be built into our timeline. It’s easy to think that we sketch out an idea, we throw it to a designer, and then someone immediately takes it and codes it. But there are spaces that need to be built into the process – gaps that allow for assessment or resource shuffling:
Management of Capacity: In most cases, teams are built out of people who are doing other things while the web project is underway. Even if you hire an external firm, you are not that firm’s only customer – you often will find times when a day or two is required to wait for the right person to gain a bit of capacity.
Review and Approval: Any time a piece of the project is moved from one group to another (from the content strategy team to the web steering committee, for example, or from development to QA), there needs to be some time allowed for review, feedback, and approval.
Testing: Testing itself takes time – iterative time, where a bug is found and then sent back and then fixed and then (maybe) found again, and static time, which consists of the act of testing itself, documentation, and setup of automated tools.
Each phase within our project stack has its own unique points of padded time as well. Often, this comes down to the fact that you cannot compress time – you cannot make the assumption that throwing more people at a piece of the process will result in a faster result. 5 Other times, there are natural points in which timing simply ... stretches out.
Strategy: Strategy and project discovery consist largely of research, which takes a lot of time, but the strategy phase often includes periods of major project decision-making, which can be tied down by anything from committee discussion and policy updates to vacations and work closings.
Content: Content always takes longer than you expect it to – either because your subject matter experts are too busy to check for accuracy or because you need to find a person who can make all of the unique content consistent – so running content editing and creation concurrently to the larger project build will always help you in the long run.
Design: Will design be created as flat files for approval and then built into front-end templates, or will they be coded from the start? Will they go through a level of design testing or will testing happen at a prototype level?
Development: Some development can be shortened with multiple people working on multiple sections, templates, or sub-sites, but there are natural bottlenecks that pop up from time to time – such as having limited development licenses as a part of your CMS install, or having a single senior-level developer responsible for the more gnarly programming tasks.
Regardless, there are a handful of project management methodologies that have been formatted for different kinds of projects, two of which will be the most common: waterfall methodology and agile methodology.
Waterfall vs. Agile, the pros and cons of each
To bring it down to its most basic elements, waterfall methodology dictates that your project will flow in one direction – forward – much like a waterfall always flows down. In this case, that stack model we keep talking about is more than just a stack: it’s a numbered list of directions. First you do discovery, then you do design, then you do development, and on and on.
On the other hand, agile methodology is focused on short sprints, where constant communication and iteration is held in higher regard than a quickly outdated master plan. While the stages may still look the same – discovery, design, development – they include many smaller loops, where the past week’s or fortnight’s worth of work is reviewed and future plans are adjusted based on findings.
There’s a good chunk of people who will tell you that waterfall is bad, and for some organizations or industries it is. But simply throwing waterfall out and assuming that agile methodologies like Scrum are going to solve every problem is usually a recipe for disaster.
For example, waterfall may seem rigid and unyielding, but it’s often also faster, since requirements are determined at the start instead of through a cycled process of iteration. Stakeholders aren’t required at every meeting once they’ve signed off on requirements, so teams that do well with delegation can really move. Testing can be faster, since software tests can begin being built from the moment of requirement sign-off. And, because there’s less overlap, each stage gets full attention at all times.
If you need to create a minimum viable product fast and build from there, now you’re talking about agile development. Working with large teams can benefit from agile since it forces everyone to be together and communicate, rather than let bad practices fester and draw out. It also allows for change, so fast-moving industries can see and react to product and site needs faster than with waterfall.
Of course, the project methodology world – much like any world that promises improvements – is vast and unending, which allows a design and development team to pick and choose from a variety of hybrid models, from modified waterfall methods with fun names like “Sashimi” to pared-back agile models like the one Blend often uses, affectionately called "ScrumBut," which means we use Scrum, but… insert excuse here.
Projects, Phases, and Sprints
Regardless of how your design and development teams decide to work, what you need to ultimately know is how they’re going to work and how that affects your timelines. You’ll also need to understand the scope of how they break the project apart – and the scope of how the project is going to be tackled in the first place.
For example, are you building a small site? Are you building a few sections of a larger site – or maybe the entire large site at once? Is this thing we’re working on a full project, a phase, or a sprint?
Some projects don’t have the structure to be broken into pieces. They are to be started, built, and finished all at once, and therefore need to be planned accordingly – from making sure everything’s present at the start, to understanding the scope of the grand launch at the end.
Then, there are those who can employ the idea of a “minimal viable product” that we mentioned before – where a base level of design and functionality is then improved upon over additional phases. This can come in two forms:
Several phases of relatively similarly sized improvements, where the full project might go from a minimal viable product of 25% to 50% and on and on.
One major phase – a full site built with 80% of potential features in place, for example – and several supplementary phases to fill out other non-crucial or “quality of life” features and functionality.
Finally, some projects never really end. They are in a constant state of adjustment and are measured not in phases, but in the individual sprints. They go through constant improvement because the industry moves quickly, or because the site is too large to halt, restructure, and launch as brand new.
To be honest, this all feels like a lot. And it is. But project planning is really just a promise.
It’s a promise for a future website, and it promises when that future will be. It’s a promise for help – and it identifies what is expected of that help. It’s a promise to keep things rolling. It’s a promise to keep things tied to that initial project spark.
Most of all, it’s a promise that you will take the project seriously. That you’re really thinking about how things will happen, who it will affect, and what your expectations are. The biggest requirement of a web project plan is that it answers questions and puts people at ease. It’s the document that gets you to your end goal and gives everyone their marching orders.
What goes into that document – and what work you do to make your web project happen – is still entirely up to you and the business needs of the site. In this next section, we’re going to start looking at how we decide what a website needs based on three things – what it already has, who it is meant to serve, and how it’s being perceived. It’s time for discovery.
Inputs and Outputs
Depending on your process, you may create a plan based on an existing project charter or project scope. You will probably bring in your business or marketing plans, and if you are doing a discovery-to-plan model you’re going to have a content inventory, audit, personas or archetypes, and wireframes or prototypes.
Your output is the plan itself, in whatever form it takes.
The Big Picture
Web planning can really happen at any time. It’s most often going to happen before the project kicks off, or before any major phase or portion of the stack. You can draft a gigantic plan for the entire site at the moment scope is determined, or you can break the project into smaller pieces (a kind of plan in and of itself) and tackle each section with its own plan.
At Blend, we’ve found a lot of success with a discovery-to-plan model, where we begin with a requirements gathering project and then scope based on real findings and project requirements. For our full-stack clients, this is a project that goes from discovery to wireframes or design, while for our development-only clients this is a technical discovery and scoping project. What this leaves us with is a detailed list of requirements that we can then both accurately bid and plan.
Planning for your team – including hiring an external partner – might come before you ever think about web functionality. In fact, you may hire an external partner to actually create parts of your web plan.
Your staffing needs for a strategic plan are going to depend on whether you do it yourself (you’ll reach out to your web steering committee or web project team) or whether or not you hire someone to handle it (during which point you may already have the basics of a plan in order to facilitate the proposal).
“Everyone Wants a Number” by Deane Barker
“Proposals Are Like First Dates” by Deane Barker
“Use Cases Part II: Taming Scope” by Tim Meehan and Norm Carr
Making It Right by Rian Van Der Merwe
Website Product Management by David Hobbs
Planning for Everything: The Design of Paths and Goals by Peter Morville
- “Why Content Projects Fail” by Deane Barker