Running projects is no easy task. Over the years we’ve been working with the web, we’ve had many successful projects, but also some less successful ones. As a web agency that’s here to stay, we want to learn from projects that don’t go so well, and improve our process for next time. This is what our process looks like today.
We have embraced agile development because it is the way of working we think gives the best result for the customer, while providing fair conditions for both us and our customer. By constantly re-evaluating the project and trying to build in small iterations what the customer needs rather than what they initially thought they wanted is incredibly important.
Working in this way presents a number of challenges. Fortunately, there are solutions to most of them. The first, of course, is time estimation and hence quotation writing. How can you estimate the time for something that you only have a general idea of what it will end up being? There is only one simple answer, and that is experience. Based on your experience, you have to try to guess roughly how much time might be needed for such a project. If the client then has that kind of budget, then you can start working.
In this way, the only thing you can do “for free” for the client that is not part of a consultancy is to establish whether or not you have the skills to carry out the project, and to give a very rough estimate of what kind of budget they must have. If you then feel you are on the same page, then the actual work can begin.
Specifying your project
The next step in the work on what to do for the customer is to gather together with the customer at a workshop and write user stories. This is simply a way of expressing what things you should be able to do with what you are building, and what functions you need to have for these goals to be possible.
So far, you have only specified quite technical tasks or general things you need. What you need to do is to work together to produce sketches, known as wireframes, where you draw out what you want. It can happen that sometimes this work challenges the user stories you have done, and that some of them need to be rewritten or completed.
Once that work is done, we try to estimate the time needed using a method called time estimation poker. Everyone in the working group sits down and with the collective experience they come up with a time estimate that is quite realistic. Now you have a pretty good estimate of how much time the project will take. It is already time to work on prioritisation. What are the most important things to include in the project? What can we put in future versions? Once the prioritisation list is ready, it’s time to get down to business.
Weekly reconciliations
It is important to have a close contact in your project. It is important for the success of the project, but also important for the transparency of the project. Here, small details have a very big impact on how the project goes.
Every week we have a meeting with the customer. On this occasion, we go through what we have done and talk about any requests and changes in the prioritisation of the project. Our ambition is to never have to extend the project beyond the budget allocated. The only way this can be done, while the customer is “allowed” to make requests along the way, is simply for the customer to prioritise.
For the first reconciliation, we have simply made a Google docs / excel document where we have written down all our user stories in the order of priority that we initially set up in Y-led, and in X-led we have then worked over time.
This way is good for several reasons. Firstly, we can work in small iterations in a simple way. For example, if the customer wants a change in User story 1, this is perfectly OK. But; this must be added as a new user story. Changed functionality must absolutely not be “included” in any existing user story, it creates a situation where it becomes very difficult to see changes in the project over time. Instead, this is added in as a new user story. This makes it clear that the client has to prioritise, and another user story may have to be pushed down to the next version (and thus included in another budget).
When the budget is over, the project is over.
By managing the project in this way, you get a product that you want, while not exceeding your budget. We usually do it like this: if we finish everything before the project budget is over, then the client simply gets the chance to cancel the job there and pays 25% of the remaining budget. If it’s the case that we didn’t fit in all the user stories we wanted to, either because things took longer than we thought, or because the client prioritised creating new user stories, then we simply have to do a follow-up project. But; the important thing to remember here is that the customer has already received a delivery on a product that works. Even if not all user stories were included, the customer has still received a fully usable product. To fulfil the remaining user stories, you either do a follow-up project, or depending on the complexity, you can also put in an ongoing support contract.
Ongoing co-operation / Support contract
Updating software, creating new features and making ongoing improvements and providing support for editors always needs to be done. With us, we do it as a support agreement. This simply means that you buy a guaranteed number of hours each month that you do what you want for. And if you don’t use the hours you buy one month, they are simply carried over to the next month. Here, we have to work out together what the right level is, and follow up over time if more or less time is needed.