Stop Complaining About Changing Requirements

Derrick Bowen
Principal, Houston Office

 

 

AAEAAQAAAAAAAArOAAAAJDVjOWJmZWI5LTZiNTYtNDJkMC04NTgyLTkxOTllN2JmNGMzZA.jpg
Have you ever been part of a software development team that complained they could not make progress because the users’ requirements kept changing? It is certainly frustrating to feel like you have wrapped something up, only to have to go back and tweak it over and over again. Even “Agile” teams, which are based around the idea that requirements are a conversation that becomes clear as you move along, often find it hard to go back and revisit completed stories.

Do you know what is even more frustrating than changing requirements? Pushing a new system into production only to have users fight adopting it because it doesn’t meet their needs. My previous article, How Much of Your Project Value is At-Risk Due to Cognitive Bias? discusses the many ways that project teams can misperceive the willingness of the target audience to adopt. Setting aside higher level political interests or organizational fears, people will adopt when they believe the value of making a change will be greater than the effort required to make that change. Essentially: if given a choice, people will adopt when perceived value > effort, and will not when perceived value < effort. When adoption is not an option, people believing that value < effort creates organizational friction in the form of reduced productivity, political turmoil, or shadow IT. Systematic biases lead us to overestimate the value of our projects and to underestimate how much effort people will require to change their habits.

So what do we do about it? How can we overcome deeply rooted problems in the way we process information? Research has demonstrated that you can’t simply think yourself out of these pitfalls, you need to expand your feedback loops with people outside of your core team. Let's start with what this means related to project execution. It is not uncommon for teams to have some form of validation process in place, but often this process fails to break teams out of their cognitive biases. In order to be effective, project validation processes need to be designed to test assumptions made by the team with unbiased external parties. The approach of early unbiased feedback is designed to emulate a scientific process and is composed of four steps: Hypothesize, Validate, Feedback, Adjust.

First, design a hypothesis on how to solve a need of the target audience. How will you help them with their Job to be Done? Define an assertion about the future state, and be explicit about the assumptions you have made that need to be tested.

Second, create something tangible that you can validate with your target audience. In software development, this could be a wireframe, clickable prototype, or your iteration deliverable. On a business intelligence project this could be a simple version of a report using a one-time data extract. When implementing a strategic process improvement, this could be a session where you roleplay a scenario with employees from different departments. The point is to do something where they can get a good feeling for what the end-state will mean to them. A straightforward way to accomplish this is to take the deliverables you are already creating for project sponsors, and use them in one-on-one guerrilla interviews with members of your target audience. To be clear, giving a presentation to your Product Owner does not count. That person is a proxy for the target audience, and is subject to the same biases as the rest of the team. Validation needs to be done with someone who is external to your project team in order to break past cognitive bias.

Third, define a feedback mechanism to synthesize qualitative and quantitative learning from the validation exercises. This should enable you to test your assumptions, reveal blind spots you were not considering, and to think about what you have learned in aggregate, grouping your target audience by how they perceive the value and effort of the change. Teams fail with this step when they don't take time to synthesize what they have learned and discuss how it should impact their project direction.

Fourth, place deliberate checkpoints in your project plan to review the feedback from users and adjust as needed. A good process will enable you to continually course-correct to arrive at the right intersection of effort and value for your target audience, while providing enough stability to your development team so they can move forward. Teams usually use the feedback from validation sessions to adjust the scope of certain features, but it is less common to step back and assess how the high level project direction should change. We should be forcing ourselves to reevaluate if we are still on track to provide real value at a reasonable level of effort.

Using this approach can help you get outside of your mindset to be better aligned with the needs and pain points of your target audience. You are likely already doing many similar steps, but are your current methods truly enough to break your team out of its biases? My goal in publishing this article is to get feedback on my approach and resources so I can continue to adjust them to be better. How valuable do you think this approach would be for your teams? What might make it difficult to implement this approach? If you have used some form of this approach, what methods of validation, feedback and course correction have you found to be successful?

Static requirements indicate that you have not been effectively seeking feedback from your target audience. Your and their ideas about the effort and value required to accomplish what they need will change over time, and if your process doesn’t allow for course correction, you are likely to create a solution to no one’s problem. Who will be complaining then?

Free Resources

You can download a feedback planning worksheet and adoption testing template rel="noopener noreferrer" I have developed here. All I ask is that if you do, please like or share this article so that more people can find them as well. If you use them, please leave a comment with your experience and feedback so that we can continue to improve the tools.

Thank you!

More Perspectives

Perspective
by David Watson
Work Life Balance
Perspective
By Russell Clarkson
Stand Up for Good Presentations
Perspective
by Kerry Stover
I Know You Believe You Understood What You Think I Said
Perspective
by Adrian Kosiak
Lessons from Dior on Becoming a Premium Brand
Perspective
By Margaret Rogers
Failing Fast Is Fine — As Long As You’re Failing Well, Too
Perspective
By Alexandria Johnson
The Hottest Thing at SXSW You Learned it in Kindergarten
Perspective
By Bruce Ballengee
Developing the Individual
Perspective
by Lori Dipprey
Why Performance Review are Here to Stay at Pariveda
Perspective
By Mike Strange
4 Reasons to Leverage the Power of Small Teams
Perspective
by Russell Clarkson
Mark Your Exits
Perspective
By Russell Clarkson
Is your Ecosystem a pipeline or a platform?
Perspective
by Susan Paul
Capabilities as Building Blocks
Perspective
By Susan Paul
When Corporate Culture Undermines IT Success
Perspective
By Margaret Rogers
Identifying the Value of Nonprofit Customer Experience
Perspective
By Margaret Rogers
Why an Agile Mindset is at the Root of an Excellent Guest Experience
Perspective
By Derrick Bowen
Stop Complaining About Changing Requirements
Perspective
By Tim Hurst
Unlocking Marketing ROI Analytics
Perspective
by Brian Duperrouzel
Hippos and Cows are Stopping Your Machine Learning Projects
Perspective
By Jack Warner
Building Smart Deployment Pipeline
Perspective
By Marc Helberg
3 Ways You Can Begin to Take Patient Experience More Seriously
Perspective
By Ryan Gross
What Does It Really Mean to Operationalize a Predictive Model
Perspective
by Sophie Zugnoni
Did You Catch Machine Learning Fever?
Perspective
By Collins DeLoach
What does Cloud Transformation mean it IT?
Perspective
By Mike Strange
Untangling and Understanding DevOps
Perspective
by Clayton Rothschild
Blockchain in an Enterprise Setting
Perspective
by Mike Strange
DevOps a Practical Framework for Technology Process and Organizational Change
Perspective
by Julio Santos
Context as Currency
Perspective
by Oussama Housini
Why DevOps?
Perspective
by Dave Winterhalter
Data in the Dugout
Perspective
By Marc Helberg
How AI Will Affect Your Patient’s Experience
Perspective
by Phillip Manwaring
Let Serverless Solve the Tech Problems You Don't Have
Perspective
by Mike Strange
Bigger is Not Necessarily Better
Load More