Your project is going along fine. After the initial bumps, the team has reached max velocity and is running through story points like there’s no tomorrow. The demos are a success, with the client loving how everything is coming together. Communication between the team members and the client is working well, with enough give and take that all sides feel like they have a genuine stake in the project. In fact, the goal posts are in sight and we’re already scheduling a release plan. And then the client asks for one more feature. Not a tweak of something already built, but a new feature that has to seamlessly incorporate into the application and not look like a last minute add-on.
The initial response? The team to comes to a screeching halt and devolves into something resembling the stages of grief.
- Denial: “But it’s perfect as it is.”
- Anger: “What!?!?!? We worked so hard to make it work and now they want to junk it up?”
- Bargaining: “Better to release it as is and then develop new features”
- Depression: “Stupid project”
Welcome to feature fatigue. Many weeks have gone into creating this software and no one is happy about adding more stuff. I’ve been through this more than once and it really does seem to be the default reaction. Why? I’m not sure — too many iterations spent solving problems? Relief that end is in sight only to have it cruelly taken away? Who knows. At some point in your career, you’ll find yourself in this situation and the question is, how to deal with it.
Hopefully, the new request will first have been filtered through the project manager rather than dropped on the team during a demo, as the first path tends to minimize collateral damage. In any event, regardless of how the request is introduced to the team the PM takes on the initial push-back, explains to the client the pros and cons of inserting a new feature at this late date and the effect it’ll have on the release date and/or other areas of the application (not to mention the cost).
It also doesn’t hurt to ask the client for a explanation of their business reason for this latest addition. This isn’t done to make the process difficult (well, not always), but rather to try and figure out if there’s something already built that will meet the business needs. And again, always good to point out the costs of adding in a new feature, especially if existing functionality will meet most or all of the business needs. These discussions will help to determine if this new feature is a “must have” or “nice to have”. It might be that building the new feature is unavoidable, but getting as much background information as possible helps everyone on the team make the best decision.
Once all this information is gathered and presented, the team can then move onto the final stage:
- Acceptance: “So fine, what’s the new schedule”
followed by, team beers.
Great article. This is why it’s so important to get the client to sign off on each important milestone (project scope, wireframe approval, design approval, etc.) When the client signs off on something, you are preparing them to pay for after-the-fact modifications.
Great post, Alice!