In today’s Agile-oriented software world, it’s all too tempting to skip the important steps of defining the work completely. There is no doubt that there is a meeting of minds between the client and the developers to end up with a product that fulfills the client’s desires and is of high quality and rapid arrival but once we get into the actual management of the project, there are differences in perspectives that are not obvious.
A client will make a request for a feature that they may be quite clear about but haven’t thought out all the implications of. In a perfect world, a Business Analyst would work through these requirements with the client in a user story to walk through how that feature should work and, hopefully, what happens after the feature works as they walk through the whole workflow.
The world is sadly not a perfect place.
Even when a BA is working on the project, we often see a feature request arrive to developers that describes the request adequately but does little to address the impact of the feature. The client’s perspective has usually shifted from “I have this business problem I need solved” to “This is the feature I’d like”. Those are two very different goals. The discussion becomes feature-centric.
The developer’s perspective is typically all about how to do something, not whether it should be done at all or if there is even an alternative to the feature.
In our office we have a checks and balances system that puts feature requests through a couple of people before they’re accepted and often results in the feature being delivered in a way that wasn’t originally anticipated but is much more effective or which avoids collateral damage to other aspects of the system that had never been originally thought out.
Still, even in my office, we end up with clients and our staff working at cross-purposes. Just like that old expression, “The road to hell is paved with good intentions,” these moments start off with good intentions.
The problems are almost always in a part of the project where change management is possible or during the user acceptance phase and the issue is wholly due to mismatched expectations.
The client, like all clients, wants a change. Perhaps they’ve now seen what they requested and on screen it looks very different from what they had anticipated. Perhaps the end-users hadn’t been fully included during the design and now that they are looking at the screens during testing, they not seeing the benefits of the new system. Perhaps the client just had an improved idea. Whatever the stimulus, the result is a request for something different and as is always the case, the pressure is on to deliver it right away.
Unlike during the design phase of a project when many resources are associated to reviewing and game-playing the work flow of a design, the request may seem innocuous but it is easy to have a tiny request become a major heartache.
With TimeControl, requests for changes from clients are usually able to be handled during the configuration of the software but even here we can have challenges. Making a key design decision about how long the timesheet period should be can have massive implications later. Should it be weekly, daily, bi-weekly, bi-monthly, monthly? We always take time to work through the implications of this as it affects how approvals, validations and workflow will work later but even here, we’ve had more than one client get through the deployment and then call to say, “I know we said weekly but could we switch to bi-weekly?” The answer to these things is often “Sure… but a bunch of your configuration will need to be redone.” In the end we wrote a whole white paper on the subject to give clients an easy vehicle to pass around all possible involved parties in the office for the discussion of that one implementation decision.
When our technical staff interact with our clients, they are always oriented around satisfying the client. That can cause heartache too. Sometimes it is best to say to the client, “I hear your request but before I say we should do it, let me walk through the implications of the request. Once you hear them you may change your mind.” However, if you’re someone who is all about satisfying your client, that’s not a sentence that is immediately thought of. Instead, and especially under pressure, a technical person might say. “I will do my best to do that right away,” not even pausing themselves to walk through the implications. Our own process catches most of these requests but some still slip through.
In the end, the best thing to think of when there are requests from a client to a developer, whether that happens during the bid phase, design phase or at any time later is to pause a moment and make sure that the thinking of both sides are on the same page.
A couple of key questions for the client to ask might be:
- How much effort are we talking about?
- What implications will this have on our data?
- Are there any implications of this request that will impact any other part of our design?
- How will we test this new feature to ensure it delivers exactly what we want?
Key questions for a developer might be:
- What is the business challenge that you hope this feature will solve?
- Are you clear that this is a change request that will affect the cost, schedule, testing of the project?
- Have you walked through this request with other impacted parties on your side?
- Have you considered how you will test this feature to make sure it doesn’t affect anything else in the system?
- Is there a way you could fulfill this business requirement using other features or in another way?
- What is the priority of this request compared to the others we are already working on?
- Is there a completed design for this request that considers how it will fit into your existing workflow?
In the end, these questions just serve to have all parties pause for a moment and ensure that the perspective of both parties are aligned.
