CLIENTS LOVE YOU WORKING AGILE BUT THEY MUST BE REMINDED OF THE COST OF PROJECT CHANGES. IN THIS FIFTH PART OF OUR SERIES ON BEST MODELLING PRACTICES, WE LOOK AT THE ISSUE OF THE COST OF AGILITY. AS USUAL, LETS START WITH THE DEFINITION GIVEN BY DAVE STURROCK ON THE SIMIO BLOG AS A STARTING POINT:
Empty space, drag to resize
“If stakeholders ask for project changes, they should be flexible in other aspects such as delivery date, level of detail, scope, or project cost.”
Dave Sturrock, Simio blog
Empty space, drag to resize
Can you spot the one word in the quote above that stands out? It is the very first word: “If”…
"Can the guy in the 8th row please leave?" - Agile requests can be costly! (Olympic games Moscow 1980)
Empty space, drag to resize
In my experience, clients always ask for changes during a project. And that is a good thing. Nobody wants to go back to where a client tells you what he wants, lets you get on with business for 3 months, only to inform you at the end that your entire work is beside their point. Constant readjustment also helps the client to focus their mind on what the model actually should do.
Agility is a very useful tool in modern simulation modelling: learn to embrace it. When your client asks “Ben, can you please add some rose-coloured animation”, it is all too easy to focus on how this will crush your plan for the week. However, there is opportunity in the request for you and your client: you can improve service for your client while your client can react to changing needs.
Of course, it is easy to hold a grudge on rose-coloured animation. It is also easy to grant any request to make the client feel good. “He sure will be pleases because I am so flexible even after this 14th change” I hear you say. Well, in my experience, this situation ends with you having lots of stress, and the client being oblivious to it because you agreed to the changes all too easily.
Mechanics fixing hull of a blimp inflight over the Atlantic (1934) - Some things need fixing while the project runs!
Empty space, drag to resize
So ideally, you navigate somewhere in the middle to deliver agility while not taking every turn. Let’s explore a strategy of how to handle requests and tell your client about the costs:
- First, clarify any request with your client. Have a quick chat of what he wants to help you get your head around it.
- In your own time, decide if it is a trivial change (you can do it 100% in 5-10 minutes). If not:
- Estimate the change workload. Make a list of all things that would need changing and how much time you expect this to take. Make sure to add your usual margin of error on top.
- Now you need to tell your client about it:
- Start with your analysis on workload change and give him the full picture.
- Next, suggest that this will increase the project time by X hours. This will mean an increase in budget by Y $ and shift the project deadline to date Z.
- Your client might respond by agreeing (well done) or not agreeing. In the latter case, suggest alternatives:
- You can move the request to a subsequent project phase. If you haven’t talked about that option yet, it is a good point to suggest that (and maybe add a few other features you think might benefit the client)
- You suggest to leave out another feature and replace it with the rose-coloured animation
Following this strategy should give you a good starting point for handling agile requests. Keep in mind that you want to help your client. Sometimes, this might include not including a request for the better of the project.
