Project planning for website development – an essential guide 

It’s been mentioned in meetings. It’s been raised by management. There’s been user feedback. 

The website needs a redesign and rebuild. Enter project planning for website development.

For you – the marketer, project lead or manager who’s been tasked with heading up the new site build – it can be hard to know where to begin. It can be tempting to bash out a rough brief and send it out to RFQ, and see what the agencies come back with. 

I urge you not to do this (yet at least). What you get back will only be vague, salesy proposals, which is what you don’t need. 

What you do need is clarity, rationale and a solid plan. 

That’s what this guide is for.

It’s a bird’s eye view of the overall puzzle, and is meant to give you the right questions to ask, the right considerations, and the right approach. It’s a planning framework.

It’ll give you the topics to lay the groundwork for an A-class brief, which you can use for internal buy-in or to then take to market for quotes. 

This guide is meant for small-mid corporate websites, whether public or private sector.  There’ll be less relevance to niche-purpose microsite or apps, or to consultants, bloggers or online stores. I’m sure there’ll be some useful take-aways though. 

The outcome

By the end of the planning phase, you should essentially have a very detailed brief, one that’s ready for project execution (or to send out for RFQ). It will be grounded in data, rationale, stakeholder input and articulate a clear vision. There will be no room for misinterpretation by either the powers-that-be or incumbent agencies. 

Here’s the high-level aspects the planning phase should cover off, of which we’ll dive into more detail:

• “The need” and project drivers
• A vision of what success looks like
• Ideation & brainstorming / blue sky thinking 
• Co-design, subject matter experts
• Articulated key goals and objectives, in both business and website terms
• Benchmarked key metrics such as traffic, retention, enquiries, other conversions such as signups
• Clearly defined audiences and target markets (segmented in personas if possible)
• A cache of available visual assets, styles, brand assets, photography, imagery
• If possible, documented research, qualitative and quantitative. Even some anecdotal feedback from customers or site users can be helpful
• Reference sites & competitors 
• Draft sitemap
• Unique layouts (map these to the draft sitemap) 
• Documented requirements: Design, Functional, Non-functional, Content 
• A project scope 
• Project plan: milestones, sprints
• Project constraints, including budget, resources and timings
• Post launch plan (future phases / iterations, feedback, analytics, maintenance)
• Agency selection
• Approval processes

Good, thorough planning has a direct impact on the quality and success of the project. This is the groundwork, the foundations to build the right asset for the business. 

It also has a direct correlation with the overall efficiency of the project. The better your planning, the smoothing sailing it’ll be. There’ll be less rework, less iterations, less changes, less testing, and faster reviews. 

Note: this planning guide is more relevant to fixed-scope projects, as opposed to iterative, Agile product development. Although an Agile approach could be applied to some aspects, typically websites have less scope for iterating and prioritising throughout the life of the project. 

Let’s get into it. 

Scout around, jot down some ideas

Setup a new folder, a new file. It’s time to start getting some notes together and collating ideas. 

In the beginning of a new web project, it’s important to come to it free from assumptions. If you have any, they’ll need to be interrogated. 

Here’s a starting point:

Sketch out some preliminary thoughts. Think about the current site. Click through every page. What’s working, what isn’t. 

Consider aesthetics, functionality. Place yourself in your audience’s shoes (or who you think they are), pretend to be them, and interact with the site as you think they would. Note strengths, weaknesses, and brainstorm some opportunities, nice-to-haves, aspirations. 

Analyse your competition and industry peers, and jot down their strengths and weaknesses. Glean ideas for your new site. 

Take the pulse

Before trying to write up anything formalised, start getting a feel for people’s general feeling about what could be improved. 

Send out an invite to a few key stakeholders and/or team members who’ll probably be involved. Call it something like “New website initial discussion”. On the agenda, include a few key discussion points and encourage those attending to bring some thoughts to the meeting. Keep it short though. It could read something like this:

Hello all, 

This is an “early days” meeting to talk through a few ideas around what a new website could achieve. If you could please have a think about:

• Who you feel are our key target audiences are
• What’s currently working well
• What needs improvement
• What you a feel a new website should achieve for the business
• What new features you’d like to see

We can get these initial thoughts down as a starting point to developing a scope for a new website. 

———————————

This will generate plenty of ideas and discussion. Record the session, and get all ideas down in writing. 

This is not the end scope though, it’s just a chance to get some varying perspectives and include the right people from the outset. 

Project drivers (the need)

For a new website to get off the ground, there has to be the appetite internally for it. Decision makers (and those that control budgets) must be on board with the investment, and see that there’ll be tangible, measurable outcomes and positive impact (and ROI) for the business. 

There must be the perception that the current site is not achieving what could/ should be achieved, and that a new site is going to deliver. 

Understanding the specific perceptions means that the “project drivers” can be articulated. It means that the project will get sign off and move forward. Some examples:

Current site issues:

• Is not on brand or positioning
• Site design is dated
• Content management is difficult
• Enquiries are low / should be higher
• Has been built on ageing or obsolete tech
• Is not integrated with internal systems
• Does not generate sales or leads
• Donations (if you’re NFP) are low
• Engagement is low / high bounce rates
• Conversion rates are low (from campaigns, SEO etc)

Opportunities:

• Re-align the site with brand positioning and messaging
• Better tell the business and brand “story”
• Provide a better overall user and customer experience 
• Drive up traffic and on-page engagement
• Reduce the path to conversion, and drive up conversions such as newsletter signups, leads, enquiries, donations
• Re-platform / rebuild on better tech for longevity (which = lower future costs)
• Rebuild for greater flexibility for design and interface changes or updates
• Find efficiencies, process improvements and reduce manual work through integration and/or automation
• Provide more autonomy to marketing/ comms teams for content and campaigning purposes

Some cost / benefit analysis and projections can be helpful too. Although it can be tricky to project specific uptick in key metrics, even modelling on base percentages (e.g. 5% – 10% in traffic, 2% increase in conversions etc) can translate to very real business outcomes and lend weight to the project drivers. 

The points above can be helpful if you have a business case to put the Executive, Board or management – but it’s also critical to understand and be able to communicate the business “need” for the project. 

Ideation, brainstorming and blue-sky thinking

One of my favourite stages!

Early on, try to put every idea on the table. They can be sifted out and prioritised down the track. 

This is often a good meeting to call after your earlier “take the pulse” meet. It’s an opportunity to put on a different “thinking hat”

Encourage team members to throw any wild idea they have at the whiteboard. 

Think about it from different department’s points of view (e.g. HR, what would they love to see on the site?). 

Think about new and better ways to bring value to your audience. Think about different parts of your business, different subject matter experts, different departments – what IP, what knowledge, what content could they bring to the table?

Think about new business models, new initiatives. 

Think about your different audience / market segments: their needs, wants, desires, pain points, aspirations. 

Here’s some examples:

• Courses or learning
• Knowledge hubs (blogs, articles, thought pieces, guides, checklists, tips)
• Communities; forums; connect professionals directly with audiences
• Calculators, tools
• Interactive components, such as maps
• Gamification
• Events
• Bookings
• Directories
• Corporate partners
• Live feeds (social, video, events)
• AI (a whole topic here, but think about data, text/visual generators, modelling)

If your site could be anything… what could it be?

Co-design

Engaging user groups to help “design” your new website can be a smart thing to do. The idea is that a “user-led” approach means the end product is fit-for-purpose. 

In web projects, this usually means engaging your audience from project inception right through to launch (and beyond) for their input. It gives you the opportunity to hear their perspectives, understand at a deep level what their needs are, test ideas out and obtain real-world, real-time feedback. 

For instance:

• Run focus groups and workshops to explore user needs (in the context of your business)
• Survey audiences for feedback on the existing site, and for general feelings towards the business “as a whole”
• Run card-sorting exercises to prioritise navigation and IA (information architecture)
• Send out or demonstrate UX via prototypes for feedback
• Run sessions to validate design concepts, look and feel, colour palettes
• Include audience segments during soft launch or beta-testing periods for feedback

It can, however, lead to much longer timeframes for projects overall. It’s also a balance to interpret the results from the co-design process. One user’s priorities may differ from another’s. The insights obtained from the co-design process should always be reviewed in context with the wider objectives. 

Goals, objectives, benchmarking

I can’t tell you how many times I’ve seen an RFQ with goals and objectives which have simply not been thought through. 

Your goals should be your North Star! Your compass! 

Goals must be specific and attainable. They are an absolutely critical piece of the project puzzle, and fundamental to developing requirements. 

This is not a goal:  “The new website should have a focus on SEO.”

Optimised for Search engines? So what does that really mean? More traffic, is that a goal? What if the traffic has completely different intent to what you provide?

This is a goal: “The new website facilitates a growth in enquiries of between 10% – 20% over a 12 month period from its launch.” 

It’s specific, can be benchmarked, and means that strategically you prioritise your scope to hone in on that goal. 

Other goals can of course be more “soft”, such as:

“The new website should be aligned with our brand and differentiate the business from our competitors online”.

Goals should correlate directly with the Project Drivers, but if possible, drill down and get more specific. 

Here’s a few more examples:

• An updated donation page – including web copy and imagery – that demonstrably increases donations
• A clear upwards trend in relevant traffic from SEO efforts
• A simplified navigation and reduced path to purchase/ contact/ enquiry/ chat/ signup/ register
• Increased on-page dwell time and increased engagement with key articles/ resources
• Leading-edge, innovative design which sets a new benchmark in the industry
• A tech stack which is modern, robust and relevant for a minimum of 5 years
• A reduction in manual processes (to do XYZ), meaning a clear gain in productivity and time for team members

Goals do not have to be purely statistical, but they do need to be measurable. 

As such, benchmarking before project kick-off is important. I won’t get into the depths of Google Analytics now, suffice to say to take note of key metrics, run reports of note and keep them on hand. Also take note of measurable metrics such as sales, enquiries, customer feedback, internal team feedback, in-bound links, registrations, email signups, site performance (look up “Google Lighthouse” and run the tool in Chrome). 

Audiences and target markets

Nitty gritty. 

You have to (have to!) understand who your audience is. Meta’s entire business model is built on understanding YOU (over thousands of data points) in order to increase your engagement time on the platform and therefore serve you more (and more relevant) ads. 

So, you can’t be Meta, but you can get pretty clear about your audiences. It’s 101 marketing and sales stuff, but you have to have it articulated in the brief. Usually, there’s more audience types than you realise. 

There’ll be your “bulk” audience – these are your current clients, customers, readership. You can segment them by demographics, psychographics, history etc. 

There’s also your prospective audiences – those you wish to engage, who you’re not. Develop personas, further segmentation. The more sophisticated and focused you are with who you’re trying to engage, the more aligned the end website is going to be. 

There’s also usually 2nd and 3rd tier audiences, such as:

• Industry and regulatory bodies
• Corporate partners
• Prospective employees, volunteers
• Shareholders
• Internal stakeholders (Executive, the Board)
• General public

Work with your team and your agency to prioritise these audiences. As with any market segmenting, the better you understand their needs, fears, desires, behaviours – the better you can tailor the website (and its objectives) to them. 

Then, these audiences can be mapped to priority “Ability tos” – or actions you’d like them to take on your website. 

Visual and brand assets

In website project planning, this is a bit of a no-brainer. 

Just collate everything you have in one place, and see what you have to work with – and what you’ll have to give to your agency for reference. I.e. 

• Brand assets (logo + variations, brand books, style guides, visual language references, marks)
• Taglines, copywriting, web copy (if anything has been written)
• Videos or animations, infographics
• Physical and digital collateral (brochures, booklets, print assets, PDFs, guides etc)
• Photography, imagery (any and everything you have)

It’s just worth having on hand, and you’ll need it to see what the team can work with. It’ll also shine a light on the gaps that may be there. 

As part of the project, I’ve found it’s often really valuable for the design team to create a “Digital style guide”. It includes things like:  Heading styles (H1,2,3, Body); bullets & numbering, table styles, accordions, buttons, hover states, active states, text-image 1,2,3 column layouts – basically every element which will be created on the site. It means that down the track if you create new content blocks or layouts, much of the work is done and readily accessible. 

Reference sites & competitors

Fire up Miro, or Figma, or something you can drop screenshots on, mark up with notes and share. 

When sending reference sites or visual stimulus to a designer (or internally for that matter), it’s better to keep it focused if you can. Too many references simply muddies the brief. 

But DO make some comments about likes and dislikes – particularly “likes” and what you’re aspiring to. I find it tricky sometimes to explain what is NOT working about a site in specific details, at least in a way that will help the brief. 

Take a look at your competitors or industry peers, especially those that are positioned similarly to yourself – but doing it better – and pick out very specific things such as:

• Colour palettes
• Design treatments and devices
• Functionality (e.g. is there a competitor’s site with a really easy to use Search function? Why/ how is it easy?)
• Points of difference
• Innovation
• How they’re engaging their audiences in unique ways

It doesn’t just have to be about websites either – there could be mobile apps you think could be inspirational, or even more traditional “above the line” advertisements. 

Draft sitemap + unique layouts

You can go and use a fancy tool like https://www.flowmapp.com/ , or really you can just use tables or a spreadsheet. 

The point is to start getting a feel for how the new site might be navigated, and what those essential site areas are made up of. 

This is just a draft too – it’s there to provide a visual reference for 3rd parties (internal or external) which will inform the scope of work. A final, approved one will be needed prior to project kickoff. 

It also gives you a sense of the interface hierarchy. You’ll generally not want to go deeper than 3 levels. Further than this and it starts becoming hard to get users down there. 

You will however have unique layouts or templates which can be repurposed or replicated. For instance, an event listing would follow a consistent layout. 

This is an important point, as the number of, and complexity of layouts, which are typically made of up content blocks, will directly impact the scope of the project, and therefore budget. 

More unique blocks and layouts = more design, more development, more testing, and more content. 

I find it useful to colour code unique templates in the sitemap.

But again, remember this is only a draft. 

As you get through closer to the end of the planning stage, it will influence the sitemap.
It may also be up to the agency to finalise. 

Requirements gathering & user stories

Requirements gathering can be a bit of an ongoing process. It won’t be something you can just sit down and do in half an hour (well, maybe you can, prove me wrong!) as it’s informed by input at every stage of planning. 

I should also note at this point that there can be a bit of a grey area between when your internal website planning finishes, agency selection happens, and final scope before kick off. 

Sometimes formal “Discovery” may be undertaken with the agency as part of the actual project, and sometimes it may be better to run this work independently. If it’s undertaken as part of the actual project, after you’ve engaged the agency, be mindful that the outcomes from the Discovery will directly impact the scope of works – and therefore costs. 

Personally, in most cases I think it makes more sense to undertake independent, separate Discovery sessions to keep them separate from the larger project engagement. 

In terms of requirements, you generally categorise them into 

• Functional requirements
• Non-functional requirements

Or you can create other categories for ease of breaking them up, such as:

• Design requirements
• Marketing requirements
• Content requirements
• Business requirements (e.g. regulatory, legal) 

I can’t overstate how important it is to really flesh out requirements prior to beginning a project. They form a key pillar of the scope of work, and of the project controls. They usually feature prominently in the contract or statement of work. They’re also key to setting everyone’s expectations correctly. 

One really helpful exercise to start getting the requirements down on paper is to list out some of “user stories”. You can go pretty deep with these, but for now you’re just getting some top-line functionality down. Phrase it like “As a …. I wish to…”. You could go further into “in order to….”, but during the earlier planning stages I find it helpful to be more high level. For example:

As an  existing client, I wish to:

• Learn about XYZ topic
• Chat to a support worker
• Understand the process behind XYZ
• Make an enquiry about …. 
• Find my nearest location to …. 

As an administrator of the website, I wish to:

• Moderate registrations
• Report on transactions
• Create new landing pages

As a prospective customer, I wish to:

• Download a free guide
• Learn about how to XYZ
• Research a topic
• Access a helpful tool
• Book a consultation

So, you can see how by identifying your audiences, and then listing out all of their user stories, this directly informs what functionality should be in the scope of the project. 

A popular model for creating these is the “MoSCoW” matrix: Must Have, Should Have, Could Have, Won’t Have. 

Based on the above, let’s look at some examples of requirements. 

Functional requirement examples

• User registration, authentication, forgot password
• User dashboard
• Online chat
• Enquiry forms
• Site search, with filters and sorting
• Location directory / search
• Online calculator
• Accessibility

These of course are all high level and need full details on each, but you get the idea. Remember, we’re still in the planning stage here – a full specification is developed in conjunction with UX, design and the complete scope. 

Non-functional requirements

These are often overlooked, particularly by marketing/ comms departments, but digging into them earlier and documenting them can really save time. For example:

• Tech stack (CMS, frameworks, programming languages)
• Responsiveness (mobile optimised)
• Hosting (scalability, uptime, redundancy)
• DNS / Domains
• Security
• Performance 
• Privacy
• Maintenance
• Regulatory compliance
• Legal
• Analytics
• Compatibility (operable on browsers, devices, operating systems)

Often the non-functional requirements are the domain of the IT department, legal or the executive, and they should be engaged as such.

Project constraints

It’s also of value to note expected project constraints – typified by budgets, internal resources, time, and risks (I could write an article on each of these topics!). 

Whilst in planning, you may not yet have a full view of the constraints. Perhaps there’ll be a new hire to manage the project, perhaps a new sponsor will emerge to find new funds. The scope of the project will impact the risk and constraints.

It’s an interplay between the different project facets. 

Define each of them as far as you can, and adjust as more information comes to light, and planning progresses through the stages.

On budgets

Here’s a scenario which I come across constantly:

“We’d like a quote for our new project.”

“Do you have a budget or expected budget range in mind?”

“No, we need an estimate so we can apply for the funds.”

You can see the chicken-and-egg situation here. The client needs a grasp on what sort of budget they should ask of the business. But a website project has to have a scope defined in order to cost it. In order to scope it, the project has to effectively begin. This is why I’m advocate for independent, stand alone “Discovery”. A measure of scoping work can happen so that at the very least an indicative budget can be formulated. 

Project scope

There’s often confusion as to what a “project scope” actually means. 

My definition is that it’s “that which defines the deliverables”.

Which of course, is a whole range of things. To my mind, it’s really incumbent on the agency to define the final scope of work. They need to pull it all together to articulate the scope, and therefore the deliverables. Here’s the main parts I see as informing the scope:

• A document or proposal of sorts which describes how the objectives will be met and the “vision” realised
• A “Specification”, which captures functional and non functional requirements
• Wireframes, which capture UX, navigation and information architecture
• Interface designs, which further articulate UX, and define all layouts and interfaces

This all goes hand-in-hand with whatever document is used to describe the “deliverables” for the project. I.e. “what they will do”, and the associated time/costs involved. Typically it should involve aspects such as:

• Project planning and initiation
• User research (if applicable)
• UX, Information architecture, wireframes
• Concept development
• Interface design execution
• Front end development
• Functional and back-end development
• Setup and configuration 
• Integration works
• Testing and quality assurance; cross browser and device testing
• Project management
• Training and hand over
• Maintenance and Warranty period
• Future phases

A great spot to be!

From a website planning perspective, things are shaping up at this point. 

If you have:

• A clear idea of your audiences are
• Gathered feedback, internally and externally
• Defined your goals and objectives
• Some aspirational ideas in the mix
• Put together some references
• Documented as many user stories as you can
• Listed out as many functional and non-functional requirements as you can
• Captured some reference sites and visual stimulus
• Mocked up a draft sitemap and mapped potential layouts
• Have a rough, initial idea of budgets and timeframes
• Engaged with your internal team AND stakeholders where you need to, vetted ideas and reached consensus where possible

You have gone LIGHTYEARS in your project planning. 

Not everything needs to be locked in stone, in fact it shouldn’t be. 

In project planning for website development, there’ll be takeaways and learnings as you engage your agency, delve into UX, start working through design. That’s perfectly fine. The important thing is to keep your audiences and objectives top of mind, and that if things evolve, it’s within the scope (and constraints), of the wider project.

Visit our web development page to see how we go about web development, or get in touch if you have a project in mind.