Projects don’t fail at the end, they fail at the beginning
Planning Profitable Website Projects is the second in the Oreo Cookie Strategy series. It’s a path to profitable website projects. You can find the first post here: How to Make Money on Website Projects – The Oreo Cookie Strategy: Part 1.
In the series, we will discuss the three layers: planning, design and the build. As with an Oreo, it’s not a cookie without the crunch. Planning profitable website projects starts at the beginning with, well, a plan. Do you have one?
There are lots of things to do and consider. There are details to gather, decisions to make, priorities to balance. Planning profitable website projects is hard. But it’s also very important. Projects don’t fail at the end, they fail at the beginning. A solid plan will set you up for profitable website projects.
What’s the Objective?
Step one is determine the website’s primary goal. Confirmation? Conversion? Something else? Do this before design or production work starts. It’s important that you invoke The Highlander here, there can only be one.
What are the Functional Requirements?
With the goal in mind, it’s time to get into the weeds. What does the site need to do, what are the functional requirements? Why is this important? Knowing how the website will function, before design starts, will have a positive impact on the budget.
There will always be at two sides to functional requirements. The website’s users perspective and the business’ needs. Both perspectives are valid, but they’re needs will be different. The users and the business will often have sub groups. For example, your target audience might be business decision makers and IT professionals. On the business side there can be marketing and sales professionals, and HR staff. Each group will have its own requirements, and it’s important to capture what they need from the site.
There are many ways to do this. We use the agile user story template: As a <type of user>, I want <some goal> so that <some reason>. The “so that” is optional, it’s not always included, especially when it’s obvious. Or you can write use cases, or just list all the things each group needs from the site.
This won’t be the most scintillating thing you’ve ever done. In fact, it’s down right boring. But it’s important to capture as many functional requirements as possible. You need all the information if you are planning profitable website projects. Know that you won’t get them all. But if you are diligent, you will have a head start.
Is it worth it? Adding requirements after starting the project, is a key source of change orders and budget overruns.
What are the Technical Requirements?
Another source of budget madness is not understanding and documenting the website’s technical requirements. Technical requirements tend to fall into two buckets. The technology required to deliver the website functionality and third party integrations.
Website Functionality leads to technical requirements
This is a teeter totter. You know what you want the site to do, the functional requirements. The website technical requirements document describes how it will do it.
In many situations, developers can use existing code to deliver a specific functionality. This will cost less than having to build a custom solution. But the existing code will have predetermined structure or set of screens that it uses. If the design follows what the code does, then it’s all good. If the design doesn’t follow what the code does, then the website will need a custom solution. This is another area where we often see budget overruns.
Knowing how the website will function, before design starts, will have a positive impact on the budget.
Third Party Integrations
Whenever the website needs to connect to a third party you have a third party integration. These can be simple, or complicated. For example, integrating a form with a common email platform is simple. It’s more complicated to integrate a form with a marketing automation platform.
Planning for third party integrations keeps the project in scope. If you know your integration requirements, you can budget for them. Needing to build third party integrations after the fact, will impact the budget, and not in a good way.
Documenting functional and technical requirements goes a long way to determining the build budget. The requirements are what drive the majority of the work effort and therefore the cost. If you have a budget, then use the requirements shopping to predict if you will be under or over budget. With this approach you can do this before design starts.
If you are over budget it’s time to invoke the first HGTV principle, “You can’t afford that. Either you need to drop something. Or you need to find more budget.” And don’t forget the second HGTV principle, there’s always something bad under the floorboards. Budget for this as well.
Determine the Architecture
Remember the five second rule. You have five seconds to do three things:
- show users they are in the right place,
- give them a good reason to stay, and
- make it clear what they should do next.
That’s a lot of things in a short period of time, and five seconds is likely generous.
Tip: The main navigation should contain four or fewer choices. Put the rest in the secondary navigation.
How do you know what goes where?
Use Google Analytics to determine what users want. Put the high value information no more than one click away from the home page. But keep things in balance. Understanding users needs is important, but so are the needs of the business. Make decisions in the context of the website’s goal.
And look at the analysis for both desktop and mobile users. Their needs may be different, which will affect what content will appear in each medium.
Lay it out Using Wire Frames
Now it’s time to map out the site. For this, we create wire frames. These are simple graphical representations of each page in the site. They show how the site will lay out, how the content will appear on the pages.
Prepare wires for both desktop and mobile. Consider whether the site will be responsive or adaptive. Are your mobile users happy with the same content as desktop users? If they are, that’s great. But if they aren’t, don’t frustrate them. Use wires to make these decisions.
The wires will also show how the functional and technical requirements will, well, function. What happens when you click an image? Will the site display content from elsewhere on the page? Will it show the first X characters or will it present a predetermined excerpt? How will the flow or screens generated by the code appear?
The wire frames are the architectural drawings. They show the designers where the walls are, and where the plumbing and electrical goes. Wire frames are not the design. They guide the design process.
Planning Profitable Website Projects – Conclusion
That’s a lot of planning, a lot of things to do. But consider for a moment what the alternative is. If you aren’t planning, profitable website projects won’t happen. You will lose money on what should be a valuable service.
A few people do the planning, bring others in as needed. This way you make decisions in the context of requirements and budget. Or you unleash expensive designers and developers who don’t understand what you need. They will do their best, nobody comes to work intending to do a bad job, but they don’t have any context. And design is subjective. Opinions abound. Does it make sense to decide how the website will look and function in the swirl of subjective, often emotional opinions?
Without planning, the expensive design and development process is iterative. You are more likely to add things in the middle, or worse, the end. “What about the…?”
The first step, planning, is a lot of work up front, but the next steps are more efficient. The first leads to a well defined scope and a profitable website project. The second leads to cost overruns. How expensive would it be to build a house by trial and error? Planning profitable website projects is a much better choice.
(Sitemap by harpreet singh)