I'm here to talk about a business problem I keep seeing. People end up in massive distress, massive fights massive arguments or just frustrating discussions about this concept of requirements. Requirements are critical to many players on a contract. Contracts officer, project managers, and analysts want to understand the deep requirements and they are important. What's wrong is requirements become front-and-centered "THE" thing that will manage a project with. That's what the reasons why I advocate and tell all my clients to go with an agile method which doesn't use requirements, at least not as a front facing in your face kind of thing, because here's a problem with requirements. Requirements are basically these weird things that everybody on the analyst, the project manager side and other players want to have this sort of a black-and-white checkbox that says, "Yes. That requirement was met."

The difficulty comes in breaking down a massive amount of information, which in the operational space has a lot going on. There are far too many moving pieces to do just requirements. Requirements are important when you're dealing with a public safety broadband network radio and you want to make sure that things are connected. Requirements are very important. When it comes down to using an application to share information from the field back to an operations center. Requirements are there. They're in the background, but really it's the operational story that matters and stories is actually when the agile concept. Because stories are incredibly powerful. Neuroscience has taught us that basically as we listen to a story. As we listen to it, our head we actually go into the story. Story can be about something I don't even understand, but my brain will actually put itself into that position and it becomes part of it. It's also how we learn. We've been a storytelling culture.. In operations many stories are abused. There's lessons learned. There's after-action reviews. There are stories during training, during exercising stories or how we communicate a wealth of information. So stories are actually where the concepts are using agile technology which actually plays throughout the rest of this issue of technology jobs magazine.

So stories are how we talk to each other. When operators talk to each other about what happened or what they would like to see, what would they like to change, they tell stories. From that though, a good analyst can take and derive.They generate requirements from the stories. They can validate requirements from the stories that problem occurs when requirements become front-and-centered. You know how to deal requirements. They don't mean anything when the senior leaders are involved. What are they doing. They want to know policy wise. What's his project going to do for him. What do I need to do for it. When it comes to policy, especially you'll look at the where are we today, where do we go, where are we going to be tomorrow, the real near future, and then that's what ought to be state. That future state down the road, in which case there's probably a story that says, there are going to be policy barriers. They're already there or they're coming and "Sir, Ma'am, we need you to stand up fight for the project and get in front of that train and make sure it doesn't hit us." Because that story is so critical that they get out and block things before policy comes into place, or governance needs to be changed. They go and make that change. You do that through stories. You explain to them what will happen if it doesn't happen, and then how the future could be given the trajectory of the story of the project we're working on. The operators again are telling stories. Where it gets really interesting is when you look at the Technical Team. Let's take the technical team who typically are the ones who want and hate requirements, because inevitably no matter how good you think your requirements are when you go to bed, when you go to do a project, whether it's an internal one that you're launching, or whether it's a formal contracting thing, generally speaking, I'll use the technical term and your requirements suck. The reality is the people doing requirements don't know the operators well enough. They don't know the senior leaders operate well enough. They listen. They read through training manuals. They may sit and talk if they're really a rare type of analyst, building other requirements. And even then things change. Things weren't documented well enough, and inevitably we are going to discover new requirements as we tell the story throughout the project. So you may as well start here, because this is where the magic happens. Your technical team needs the requirements, and they can derive them, but they must derive them from stories.

I put a two-way arrow here, because the stories from the technical team, talking to the operators are just as important, if not more important. The operators need to be engaged, if they read requirements. They're gone. They're just out of there. If you're an operator, if you know what I'm talking about. If you are not interested, if it is not relavant, then it is just out of there. You move on to something else in your head. You may be sitting in there, but you are gone. The technical team now must tell a story in an operator speak. There are technical pieces behind it. They need to translate it, tell a coherent stories that we all understand to get on the same page, and we can all tell the same story. Your operators can then tell the tech team where things are wrong. Tell them a little slightly adjusted story. Now you missed this point. You need to go do it this way and we don't do it that way. We can't do it that way. Here's why. Those aren't requirements. 

Why I want to get across, it's all about the stories. It's not the requirement. Requirements, they're important. But if you're not telling stories, you're going to be in trouble. Hopefully that helps. I'm Darryl O'Donnell from technology OPS.