How Agile has helped me price web projects

One of the benefits of moving to an Agile approach, for me, has been the confidence it’s given me with pricing projects.

That might sound paradoxical as Agile is about letting the process determine the cost, rather than fixing them upfront.

But, that does not mean we have to be suspiciously vague or evasive when asked “how much?”.

We’re not toting a spurious sales formula, but a model that’s altered budget spending in banks, governments and the world’s largest companies.

Being able to offer an agile approach should give us an advantage as it’s all about delivering value to the customer. That said, it can be wrongly applied or lost in translation.

The elephant in the room

A week before this blog went live it had a different domain, a different main message and posts. It was orange, had different icons and had a serif font.

After building countless sites since 2006 you would think I should be able to stick to a plan, but that’s the nature of the creative process.

The more important a project, the faster ideas evolve and the more sensitive we become to outside influences.

For clients this can be more problematic. They are not often expecting this and commit to plans with far less knowledge than us.

If they become similarly invested (which seems to happen when the designer has something to show) they can find themselves cornered by their own initial intentions.

A form of cognitive dissonance can occur which, if not easily reconciled, creates problems for the project.

I used to read the Clients from Hell blog and clearly some had found themselves conflicted. Similar to how end of the world predictors become even more adamant they were right after the date has passed.

Psychology is one of the reasons a people focussed Agile approach appeals to me. I see it as a way of not getting caught in the crossfire of a client’s conflict with themselves.

Of course, It would be easier if clients remained with the same level of personal detachment as when the project began, but unless they agree to entirely leave it to us it is probably not realistic.

On the plus side, the more they are invested, the more likely it is they will explore further what the medium has to offer. That can translate to more work.

The customer’s always right

The chances are a client will initially have no good reason to expect anything other than a fixed cost proposal.

This is where an agile designer could blow it with good intentions the client is not in a position to appreciate yet.

Often the solution is simple. Give them what they want…

Plus, the ability to change their mind without losing face!

For freelancers and small agencies this should be relatively easy:

• Most of us can reasonably predict the time it takes to fulfil the build without the client.
• Payment for sprints of works are (to a client) the same as scheduled payments for fixed cost projects.
• Scrum like team work, for us, will often be periods of us just getting on with it (more on this topic in later posts).

Essentially, the agile approach is there to give the client flexibility and a way to be more closely involved.

If they want to forgo that for the certainty of a fixed cost that’s understandable, but they will then need to follow our process.

If they want us to respond to creative changes and work together they have to accept they are now in charge of setting the budget. We can only use our experience to help with approximates.

What I’ve found so far with agile (as we should expect) is that jobs that remain similar to the plan have come in at less than they would have with an upfront fixed cost price.

It incentivises focus which cuts down chasing, stopping and starting and written communication. Plus the client’s time is used for doing rather than undoing what has been done.

Either way we remove the friction that can occur when clients become contracted to ideas they had when they were less knowledgeable.

Signalling intentions

Selling websites as a commodity was once a good part of my work.

Although often still very personal to them, they were mostly tokenistic appendages to their business. “Build it and they will come” was the prevalent view of the time.

This work has been drying up since the emergence of code-free page builders and ready made templates.

Clients still come asking for “a website” (often requiring functionality they are not sure how to achieve), but what’s become easier with time is getting to what most really want, which is a strategy to get more business efficiently.

They either have got a better glimpse into digital marketing or they have built it before and they did not come (or got confused and distracted and left).

These are the clients I feel I can help the most through a longer term relationship and this seems a better deal for both the clients and myself because:

• If they come on my hosting and care, I have a way to stay in business, not get overwhelmed with odd jobs for an increasing number of clients and be available as long as they need me.
• It’s not in my interests to try and spend their entire budget on a big launch. I will be incentivised to help them spend according to actual results over a longer period.

Obviously at the start of a relationship I want to make it clear I am not trying to lock anyone in (for my sake as much as theirs).

I simply want to offer a service appropriate to the changing nature of the medium.

As a website is never really “done” and one of the biggest gripes of clients is that their designer is not available when needed, it makes sense to build trust relationships and useful allies.

So far, since explaining this, everyone has paid a year of hosting and care before anything has been built. The proposition made sense to them.

The only exceptions have been a couple who were trying to secretly “cheat” on their existing designers who they thought would charge too much.

Creating an impression

I don’t have a set onboarding. It is very loose and led by intuition and these days I don’t take on many new clients, but I thought I should end with a flavour of my approach.

The first contact with a client is usually through a face to face online chat. I don’t seek information budgets because:

• Most won’t know or will not want to show their cards yet.
• I‘m interested in the lifetime value of a client, where they are likely to be thinking about a one off project.

Most will have shared a link to an existing site (or an example site) and the first part of the conversation is looking at that to see if I can do it with my trusted tools.

I am happy to refer to it if not as I don’t want work I feel will be problematic to maintain in the long run (business growth for me comes through hosting and care which I want to keep as passive as possible).

After this I can usually find out a bit more about them, what the site means to their business and how hands-on they want to be (during the build and afterwards) before we get the “how much” question.

Generally I am quick with an estimated cost based on likely sprints of work and then I go on to explain how my business offers two routes for them and why.

If I discover that getting more leads is key to them I will talk about me doing some keyword research for them. This is because:

• It’s a low cost way getting to know me and my value.
• Knowing what keywords we can compete for will give us clues on layout and content for the project (rather than undo work later).
• It is something that I say I will refund If I start and can see nothing of value to them.

On occasion I have mentioned that we can start with a landing page. That can go live and potentially start  getting an early return. That work would become the finished homepage. This could be a good way to know if we can work together. If it fails early we will cut our losses quickly and respectfully. I am putting myself in their shoes with the risks.

I have never needed to talk about agile or scrum to them. A simple account of how I have tried to make my business fairer has been enough.

If not obvious, I do check that I am talking to the decision maker. If not I explain that I work with one person. In Scrum terms they become the Product Manager. In terms of my business they became the account holder and client.

If it is likely they may need me to attend meetings with other stakeholders I suggest they do that as a separate payment so they can control the cost there.

Sometimes they may throw things at me that I need to think about. In those cases I will send them a video screencast of the options and what I feel might work best (if I have understood them correctly). It is the closest I get to a proposal.

Generally I send them links to pay for the hosting and book the deadline for the first sprint and they book on the same day.

For many clients the build is going to be more traditional in practice, but I feel Agile thinking has been helping me to put myself in the client’s shoes and set expectations better.