Summer Read Along: A Seat At The Table | Chapter 5 – Requirements

In this series of blog posts, follow along as we revisit Mark Schwartz’s book A Seat at the Table: IT Leadership in the Age of Agility. Five years after its publication, it’s still highly relevant and chock full of tips, tactics, and learnings. Join us as we follow along with Online Marketing Assistant Lucy Softich as she reads through the book for the first time. Make sure you start with the introduction post!

Today we’re going to look at Chapter 5: Requirements. Much like the last chapter, which focused on planning, this one asks us to reconsider the words we use and whether or not they mean the same thing within an Agile framework as they did in a Waterfall framework.

Redefining Requirements

Mark begins by looking at the word itself:

A requirement is a constraint. It is a way of saying “create value this way, rather than other ways.” Really, a requirement is a constraint masquerading as a decision.

Under traditional control structures, requirements are delivered to IT from the business and used to control what IT produces. A tool of traditional planning, if you will. And like traditional planning, they limit the creativity and ingenuity of the people the business has hired for those very traits. Requirements, as Mark says, put a constraint on what people can produce, which can keep people from seeing past those requirements to the real potential business value.

If we’re being literal, a “requirement” should be something that the business cannot live without. And yet, they are currently living without it, or they would not be requesting it from IT. We can say the same for “needs,” which are likewise really just a term for something the business wants (or thinks it wants).

Re-Focus on Outcomes

As we continue with the Agile thinking we’ve been applying to leadership throughout this book, we must change the definition of “requirements” to be more flexible. Mark redefines them as “hypotheses.”

What we have traditionally called a requirement may better be thought of as a hypothesis… Although the purpose of the requirement is to add business value, there is no way to know with certainty at the time it is formulated whether it in fact will add business value.

Again, we come back to business value. Or, in other words, outcomes. Suppose the business and IT leadership define a desired outcome, a business value they can deliver through IT, and then take that outcome to the department. In that case, IT can do what they do best—use their knowledge, experience, and creativity to find the best way to deliver this outcome.

This system (focusing on outcomes instead of requirements) still allows for a necessary constraint—once you have delivered on the business value, your task is done. You may need to maintain and adjust in order to keep delivering that value, but there is still a clear goal, a clear end-game. If IT discovers a different or better value in the process of aiming for this outcome, they may choose to re-evaluate. This is yet another place where the CIO can step in and use their perspective to refocus the team.

With a flexible, Agile mind frame, IT leaders can focus on desired value, and let the ones doing the work figure out the steps to get there.

—

Jump to a Chapter

Introduction & Chapter 1
Chapter 2: Kept from the Table
Chapter 3: A Nimble Approach to the Table
Chapter 4: Planning
Chapter 5: Requirements
Chapter 6: Transformation
Chapter 7: Enterprise Architecture
Chapter 8: Build Versus Buy
Chapter 9: Governance and Oversight
Chapter 10: Risk
Chapter 11: Quality
Chapter 12: Shadow IT
Chapter 13: The CIO’s Place at the Table & Chapter 14: Exhortation and Table Manners 

- About The Authors

Lucy Softich

Lucy is the Marketing & Social Media Coordinator at IT Revolution. She has a background in writing, marketing, and business.