Many times clients will expect a fixed budget and a firm deadline. That means a contract based on a set of fixed deliverables, and a project typically confined to those deliverables despite of any changes/challenges that may come up along the creative process.
But, what should you do when you want to get your client to work with an agile methodology? How can you convince them to trust the process, and what are the things to keep in mind to ensure expectations are managed?
Make it clear: agile is not synonymous to the absence of deadlines and budgets
When you are not working the typical waterfall process, it may seem like you won’t be setting deadlines and budgets. No client would jump on board with this however, nor would you really want to manage client expectations without any of the guidelines discussions over deliverables, deadlines and budgets help set.
Let’s look at the root of the issue: clients typically find it harder to go for an agile methodology as it can be scary to not understand what you will be getting out of your investment. So, make things easier: to kick off analyze the client’s needs and work with them to set the goals of the project, then agree to a number of story points tied to a certain budget. This way you maintain flexibility, the client is guaranteed to get value for their money, and you can bring the discussion closer to the deadlines/budgets mentality clients feel more comfortable with.
Note: It may be useful to explain that where your client not to ask for any changes in the backlog/scope, this would be the same as a fixed price/scope project. In the case of agile, though, you have added flexibility – much needed in creative processes for optimizing results.
Be sure to also make clear to the client there will be a frequent delivery of working prototypes/samples for monitoring the progress and providing feedback as you develop each of the stories. In most cases this will be exactly why you would suggest agile in the first place, so you can have more iterations – based on feedback – before you get to a version your client would feel comfortable sharing with their audience.
Note: Don’t forget to outline the benefits of being able to make iterations during the process – taking into account user feedback as well when possible. In the end this can help save the client costs while also opening the way to a more successful product at the end of the process.
Manage expectations of involvement
Expectations management has some added difficulties in this scenario. For many clients this will be a new process, so you want to make sure they clearly understand what to expect, as well as what will be expected of them. Often the focus is more on what will be delivered – what you and your team will be working on – rather than on what is needed from the client – in other words what your client will be working on.
Feedback is what keeps your process moving, so your client answering questions nearly immediately is crucial. They need to expect, and not underestimate the amount of involvement needed on their end. Thus, you should clearly explain how delays in review rounds can affect the process, and make sure you agree upon clear deadlines in providing feedback.
Note: In bigger companies immediate feedback can seem unattainable, but perhaps you can get around big-team-delays by having one person on your client’s end be the main decision maker for your project.
Also, don’t forget you will still need a clear view of their project needs, so you are aware prior to a kick-off meeting which member(s) of your team or which external partner(s) you will need to involve in this process. As you will want key members of the project team present when brainstorming/estimating with the client, it is essential you have a clear overview of who to bring on board.
Have a clear brainstorm/kick-off meeting
Once you are ready to talk specifics, plan a meeting with the potential customer and bring along the developers working on the project (the term ‘developers’ is used here to describe key members working on the creation of the product not only programmers). Lead a brainstorm setting the acceptance criteria – here you understand what is important to the client, and together set a list of goals. Then, based on the goals agreed upon, the developers estimate the work in story points during the meeting.
Note: Keeping the client present during the estimation process you promote transparency and build trust. It also allows them to better understand which aspects of the project are a bigger time investment and then can take this knowledge with them when discussing priorities/backlog.
Now you can provide your client with a budget based on the estimations set by your team, as you can create an overview with all stories and their costs analysis. With this in mind you can sit down and together fine tune the backlog/scope and timeline of the project.
Note: If your client has a limited budget to begin with or wants to start with a small investment to test out the process, break down the project into sets of stories. Prioritize what would get you to a “minimum viable product,” and create a backlog for later stages of the project.
Keep the lines of communication open
Agile works if you keep your clients informed of the progress regularly. You should produce a progress report at least every two weeks – sooner for short term projects. The progress report should state the % of story points completed, and % of the estimated time used, as well as the % time still available on the overall project budget agreed upon – be detailed to make sure no confusion is created.
You should – of course – also send working samples along with your progress reports to get feedback on the deliverables, allowing for iterations on the process as well as a feeling of ownership of the deliverables in your client. Though to be clear, your client should not be your Product Owner, they will be greater advocates of your project if they can claim a sense of ownership over the process and the deliverables.
Note: If your client is late with responding, make sure you ping them reminding the delays in the overall process a delayed feedback round can have.