As a freelance software developer you’re in a constant struggle between client, project and managing expectations. There are so many pitfalls that could result in an unhappy client and a failed project.
Scroll down to watch the video!
In this talk I will explain what helped me managing this. I will explain what steps to take when you start the project and what steps to take when you’re in de development phase. In the end this is basically a one-person scrum process which sets up a communication loop with planned iterations and intervals.
It is also about asking the right questions and making the right comments and remarks at the right moment. With a good project startup or alignment you will be put in the driver’s seat instead of your client.
To elucidate this process let’s start with the worst possible project management approach which I call the trust-me-i-am-a-wizard approach. The steps are the following:
- Your clients tells you what he wants
- The requirements and deadline are mailed
- You start development
- You deliver just-in-time
In the end, this will result in almost all cases in a product that is different than what you client expected. First off all, as a developer, you probably lack a lot of context; why does the customer need the product, what does he or she want to achieve with it. So instead of a set of dictated requirements, find out what he really wants. This will give you the ability the weigh requirements and instead of blindly follow what your client tells you he wants, find suitable options that will better suite the project, given time or even the expected end result.
After the first step, when your client tells you what he wants, you should start looking at yourself. As a freelancer this normally results in making a planning but instead of filling in what you want to deliver at what time, first look at your own availability. How much time and effort can you spend on this project and be realistic. Now look at the available amount of time you have available before the expected deadline and subtract some time because you don’t want a last minute delivery. Also consider some additional time for actually delivering the product in the expected delivery environment (e.g. submitting the app to several app stores).
You should build a backlog of stories and place all work that needs to be done in there, even non-functionals. Also discuss with you client what features definitely need to be in the product and what are nice to haves. Whatever is a requirement before go live should be place what we call the Minimal Viable Product or MVP for short.
This is the first time you should ask yourself the question: “is this, what the client expects, realistic, for me, to do in the given amount of time?”. This is no simple question and most developers with a largely positive attitude (including me) will probably say it is realistic. But, in the end, every time you ask yourself this question you should get better answering it. And even if you’re wrong, following the process will give you enough time and opportunity to rectify this. You should also tell your client about the process you are going to follow, what you expect from him during this period and what possible risks are. One risk is always that the requirements need to be reevaluated during the process to make sure the deadline is met. In case this is no option, the deadline should be shiftable. In case this is no option, you should start asking yourself wether you want to do this project.
Then you should divide the time towards the deadline in short and manageable iterations. Each iteration is the same what you call a sprint in scrum but instead of having several meetings with a team, simply end each iteration with an appointment with the client. During this session you should show the current state of the product. This means that every sprints you should be able to show something and produce a deliverable product that enables the client to give constructive feedback. It is also a best practice to first start with stuff that has a high risk, either from your perspective or the client’s or the project’s.
During this meeting you should reevaluate the same question you asked yourself in the beginning: “is this, what the client expects, realistic, for me, to do in the given amount of time?”. A soon as you feel an itch, you should act to that. Talk to your client; tell him the risks but also give him a solution. The absolute worst case scenario is here that the project gets cancelled and although that is not a desirable result, this is better now than after the deadline. Because of that your iterations are short and you start with the most risky items first and you keep your client in the loop ánd already told him about the risks, the change that this happens is really small. The change it backfires on you is even smaller because you kept transparent about this. Right? Most of the times you should simply need to adjust the MVP.
One sprint prior to go live you should start with the project conclusion. Check with you client that all MVP deliverables are met and determine what the client wants to do with the rest. Maybe there can be an additional release? Also agree on some sort of agreement about support. Is there a grace period for bugs or some other form of warranty. Should the customer want a next release, simply start over again with the process.
In the video below I will explain the process in more details and answer several questions about how I handled (or should have handled) these kind of projects and related stuff like estimations during my talk on the NextBuild 2017 in Eindhoven.