I feel like I’m beating my head against a brick wall sometimes.
I was just talking to someone in my company about the need to encourage our [company’s internal] client to put thought into their requirements up front and make a bigger effort to ensure that they’re fixed before providing them to my development team to start on.
The argument against was essentially, “They’re paying the bills so they should be able to change their mind as much as they want” and “They’re paying us so we should just do what we’re told”.
While I recognise and agree that the client should be able to change their requirements (especially when using a Lean or Agile methodology), I also feel that there should be a point at which some (any!) fixed, approved and signed-off requirements are supplied to my team. I’m therefore trying to implement a simplified Lean Software Development process that requires the client to have fixed a set of requirements (not necessarily everything; just enough to keep my team occupied for a 3-week development & testing iteration) before work can start.
This allows me to:
- Provide a more accurate estimate
- Plan my team’s resourcing (I’m the Team Lead)
- Create Work Items in TFS (or Stories if I’m using an Agile flavour)
- Write unit tests ahead of development rather than after the development is in a state where it’s not going to change anymore
- Provide reports at the end of an iteration of – for example – actual effort cost vs estimated
Is the argument of “They’re paying, so just do what you’re told and don’t argue” a reasonable one? What are the counter-arguments if not?
If the client (or internal business reps in my case) holds the view that:
- they don’t care about how many times my team has to do their work over again
- they don’t care if expected delivery dates need to be moved out
- they aren’t concerned about the wastage incurred with all the do-overs
Do I have a reasonable basis for concern?
Thanks for the great question! Since your dev process iterations are already 3 weeks long the solution would probably not involve improving risk management (for instance, pushing requirements that are likely to change into the end of the development cycle) or expectations management (making your team aware that changes are inevitable). Instead I’d suggest a few things:
Putting up higher formal barriers for any requirements change: forms, approvals, impact analysis, change management process.
Creating an up to date road-map together with the business users to give the development direction and focus. This will also give a way for various users to resolve their priorities and reach an agreement on how the limited resources are spent.
Finding the courage to say “no, not in this release, and probably not in the next either” and stand your ground.
The latter, the courage not to give in and agree under an intense pressure to the changes that will put the project and the software product into jeopardy in the long run is one of the toughest parts of the software development project manager job. More so because often you won’t have any hard data, the impact of the change might seem uncertain and often negligible. Unlike products in construction or mechanical engineering trades, software is inherently malleable and making a little change might seem as no big deal to everyone and it might not be a big deal, but then another one, and yet another one on top and soon you lose track of the original design.
Developers are often critical of their management who allow the requirements change through late in the project. However, the stakeholder pressure is intense and often PM feels, even if it’s just implied, as if it’s their job or career is at stake, on one side of the scales and just a vague gut feeling on another.
Not saying that there shouldn’t be any change allowed at all, there is a seamy side, sometimes change is crucial for success. And it is all about knowing when to give in and when to firmly stand your ground.
One of key management tasks is to design the development process and designing the software development process is akin to designing the software itself: it’s all about finding good trade-offs between conflicting requirements and, at the same time, staying within constraints:
Programmers prefer having as much information about the task at hand and as early as possible. The requirements are needed to create and validate software design. And the late changes are disliked for a reason: they force programmers to re-evaluate big chunks of the design and go through the validation process again. This requires a lot extra time and care on their part.
Development managers prefer to plan based on stable requirements that are well known up front. Most planning techniques assume a great degree of certainty, at least in the short to medium term.
Business users, would love to have zero lead time for implementation of changes required, they’d like and often would have a genuine need for flexibility to change the requirements as late as possible. After all this creates a huge advantage over competitors. However, regardless business wants to be able to maintain or even increase the rate of software change without increasing the resource; the business also assumes that any software solution delivered is going to be robust.
But all three groups are often oblivious of each other needs:
Programmers don’t have the knowledge of the business urgency, window of opportunity, completive advantage or compliance threat the change will address.
Development managers time and again seriously underestimate the effort required for the re-design; or just lack the courage to stop business users from shooting themselves into a foot.
Business users are just unaware of the lead time required to deliver a piece of software, the development process is completely opaque from where they are, it just seems that things start taking longer and longer to happen and the end product is a complete mess.
Some tips:
Always do your best to have a clear and up to date overview of priorities and outstanding work, failing that you’ll lose any requirements negotiation before it even starts — you’ll have no facts to argue your position or re-negotiate the schedule, re-shuffle features and will have no other choice but simply succumb to the pressure and promise the impossible. Hence have:
An up to date schedule.
Clear descriptions (or specs) and estimates (even if it’s an order of magnitude) for all outstanding tasks.
All outstanding tasks in writing, stored in one place.
On the outset of a project identify the requirements that might change:
Schedule them as late as possible
Set dev team expectations; explain the way the business thinks and any existing constraints
Aim at providing a more generic functionality, seriously weight excluding from the software anything that is bound to change and can be easily handled in other ways.
Look out for political requirements, i.e. requirements that do not have any other sound explanation.
Establish a clear change managements process:
Formal process will make changing requirements more expensive, hence many whims just won’t make into your list.
Have the courage to say “no”, when you think the requirement will endanger the project.
Avoid going over the top with the formal process, it’s just a tool; don’t risk completely losing touch with the end users and stakeholders.