Can you afford to skip the pre project?

You work in an organization or company and have been given the honorable task of fixing a new website. The stakes for you are high, as the person who is ordering and perhaps leading the new website project. Who are we going to work with, what are we going to build and not least: What will it cost?

To a certain extent, you know what is needed, and a requirements specification is created.

Then you ask around if anyone knows of anyone who is good at creating websites. Or maybe you Google a bunch of agencies and take a look at who they've worked with before. Finally, you have your list ready and send off an email:

"Hi agency x.

We at company abc are going to build a new website, and are wondering if you could be the right agency for us. We have created a simple specification, and are wondering how much something like this might cost, and when it can be completed. Looking forward to hearing from you."

Attachment: Requirements_specification_new_website.doc

The first response you get from Dekode reads something like this:

"Hi x.

Thank you for your inquiry. At Dekode, we have extensive experience in building websites, and would love to help you. In order to be able to provide an accurate estimate, we recommend conducting a pre-project to get to know you and your company better......
We are happy to meet with you to understand a little more about your needs.

This fictitious email dialog above is a pretty good example of a cross-section of inquiries we at Dekode receive in our inbox.

In ten out of ten cases, we will say that we recommend starting with a pre-project together. We understand that it can even be a bit annoying, when you've spent time on writing a requirements specification and expect a price and a launch date in return. Preferably with two dashes under the answer.

What exactly is a pre-project?

Having worked exclusively with the web for over a decade, the one thing we can say with 100% certainty is that no two website projects are the same and no two processes are the same.

We believe that the pre-project is the most important part of a web project. Skipping or de-prioritizing this phase is the biggest indicator of whether a project will be successful or not. Done right, it's the foundation that ensures we create the right things that can have a direct impact on the company or organization's value creation. Done right, it can become a tool that assists a web editor
or marketing manager in their everyday work, which in turn contributes to efficiency and time savings.

A pre-project has several purposes

In short, the purpose of the pre-project is to define what should be made at what price.

You'd think it should be simple, but there are many elements (often more than you're aware of) that help define both scope and cost for the project.

Insights

At Dekode, we want to be proactive advisors, and we are confident that our experience from working on many digital projects will add great value to your project. But in order to have the the right prerequisites to be able to make sense of things, we need proper insight from you as a client.

• We need insight into your business goals and ambitions.
• We need insight into your organization, competence and ability to execute.
• We need insight into your target audience.

When we work through this together, we can also provide good advice and help to quality assure your specification.

From goal and vision to concrete measures

When someone is building a new website, we at Dekode consistently call it a launch project. A lot of requirement specifications have a tendency to be all-inclusive. That is, as much functionality as possible. This often becomes intangible, and not least unnecessarily expensive.

Through the insight we gain in the feasibility study, one of the most important tasks we can assist with will be to prioritize and concretize.

What do we need to launch in order for you to start reaping value?

• It's about focusing on the most relevant target groups.
• It's all about knowledge and mastering technology and digital tools before pouring on the features.
• It's all about filling the solution with good, well-designed content.
• It's about creating good processes and work routines in everyday digital life. 

We often end up scaling down the specifications for a launch project. By not overdoing it, we increase the chance of success with the first step. Customers who experience mastery and digital maturity will quickly be able to raise their ambitions. This allows them to approach strategic ambitions, step by step.

Internal target groups

The most common reasons we hear about why someone wants to build a new website are:

• the current website is not flexible enough. 
• that it is too difficult to make changes.
• that the client wants a supplier that can offer hosting, maintenance and support. And ongoing development over the next coming years.

The paradox in all these points is that they are very difficult to define in a requirements specification. The vast majority of what is described in a requirements specification is about user tasks and functionality linked to an end user, i.e. those who visit the website. But what the experience and flexibility of an editor should be like is rarely mentioned.

A function that does the same thing can be solved quickly and easily and look absolutely perfect on the website. But if the same function is to be made flexible so that the marketing department can update and change as they wish, it will require more work to implement.

Most requirement specifications that come to us mainly focus on the end user.

This contributes to the fact that a website may not be flexible enough, or easy enough to update. This reduces the lifespan of a website.

In a pre-project with Dekode we will always include their internal target groups.
This can have a surprisingly large impact on the specification and estimate.

Internal anchoring

It's worth noting that many people see a website project as something relatively simple. However, in our experience, projects often end up interfering with the overall strategy, as a website is in many ways a window into the inner workings of the company or organization. On several occasions, we have experienced that a website project has acted as a catalyst for major internal reprioritization.

For this reason, it can be important to include and involve relevant managers in the pre-project phase.

Get to know us

"We are looking for a long-term digital partner". This is typically something that appears in most of the inquiries we receive. And rightly so. The number one indication of success in digital is whether the company or organization has a long-term perspective on what they do.

This means that for most people, the initial project is just the start of a longer collaboration.

A good collaborative climate where we enjoy working together will be important for all parties, and a pre-project will be a good opportunity to get a feel for this.

Risk

The sum total of all the exercises and clarifications made in a pre-project are intended to reduce risk and in some cases indicate risk. Unless you have a very elaborate specification, we would argue that sending out a request with the expectation of a precise estimate is a bit of a shot in the dark.

All suppliers interpret a specification differently and, not least, there are many ways to solve different challenges. That in itself represents a major risk.

Requirements specification and cost

For most people embarking on a more or less complex web project, the biggest uncertainty is what it will cost?

No one likes uncertainty.

The purpose of a pre-project is to define a specification on which it is possible to give a precise cost estimate.

As we hope to have highlighted in the sections above, the price depends on many factors that you can largely influence. In many cases, our ambition is to scale down the launch project and instead have a long-term plan so that the web solution quickly becomes part of the value creation. For most people, it's easier to invest a little bit at a time when you can see that the website contributes to revenue or some other form of goal achievement.

Not everything can be estimated

Most of the time, we have a gut feeling about the scope of a project. However, there are some things that are notoriously difficult to estimate, even after completing a preliminary project.

Integrations with third-party systems often create a lot of uncertainty as not all third-party systems have good and correct documentation. Where possible, we will look into this in depth in a preliminary project and be able to come up with a rough estimate. But in some cases, more thorough technical investigations are required.

What does a pre-project cost?

As a rule of thumb, a pre-project costs between 5 and 10 percent of the project's total budget. We believe this is a relatively small investment to reduce risk for all parties.