Chapter 4

Create a Project Plan

Summary

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.

Narrative

When you think of a plan, what do you think of?

Do you think of a consecutive series of steps, 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, like a maze with multiple correct endings?

For a web project, planning is often a mix of both. We like to compare a web project to a building, where user requirements 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 assume 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, a web project has more moving parts. The web is complicated, which means planning for the web is complicated.

Of course, because this is 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 defines high-level expectations and requirements around 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.

Episode 4: Create a Project Plan (w/ Brett Harned)

Corey and Deane talk about how project plans rarely stay intact upon first contact with real life. Then, we chat with Brett Harned, author of Project Management for Humans, about his definition of a project plan, creating better retrospectives, and how to help clients and project teams keep on track. (Also, Brett tells us the best album in his record collection.)

Brett Harned

Past Episodes

The Strategic Project Plan

First, you need to document the expectations and high-level requirements of the site. That’s the strategic project plan. But while the strategic product plan pulls from a variety of different sources, whether it be your marketing department, your IT department, or some kind of stakeholder survey, it is not a detailed manifesto.

Instead, 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 strategic 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. 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, 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)
  • Success measurement
  • 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; on the other hand, 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? 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

At this point, with internal teams formed, you realize where the gaps are. You need a plan of action for hiring someone to fill the gaps. That’s where a request for proposal — commonly referred to as an “RFP” and used to formally request some kind of professional service — comes in.

Know this: in most cases, a request for proposal isn’t required — they are for most projects funded by public money, but otherwise they are completely optional – but they 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. They can be 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.

So how do you do this? We have some tips:

BE SELECTIVE

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:

  • Desperate firms who need the work will respond to anything.
  • Selective 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

Websites aren’t just containers for features. They’re tools for providing outcomes. If a person visits your site for a specific reason, the site should fulfill that reason. Which means, rather than a giant list of requirements, your RFP should ask for a narrative response that tackles process.

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 thing 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 (AND YOURSELF)

We know: the unspoken rule of agency life is that you never let anyone know 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 choose not to take on smaller projects and those who are too small to take on gigantic projects.

Every web project, no matter the phase, requires a budget for three separate things:

  • Money: How much will this project cost in actual This is the most obvious.
  • Time: How much time will this project take up? For some organizations, time is the same as money – the twenty hours a week that your internal content strategist spends on a project is twenty 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 initiative sprouts up.

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.

Understanding Timing

So, how long does a website take to build? You might as well ask how long it takes a person to drive home from work – 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 coordination and management time, 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. These spaces might include when the core team is focused on their other day-to-day work, or when things are waiting for review, approval, and testing.

Each phase within our project stack has its own unique points of padded time as well. Working on strategy requires a lot of decision making, which leads to periods where stakeholders might mull things over. Content always takes longer than you expect. And development has its own unique challenges due to differing abilities within the team or license hiccups.

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. On the other hand, agile methodology is focused on short sprints, where constant communication and iteration are held in higher regard than a quickly outdated master plan.

Some people 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 really need to 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 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 a promise.

It’s a promise for a future website, and it’s a promise for a future launch date.

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.

Staffing

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).

Resources

Articles

Books

Presentations and Other