In the previous posting, I spoke about one of my key guiding principles for how I approach requirements gathering and writing, “asking permission and not forgiveness”. It was prompted by an interview question that was posed to me recently. In this posting, I’m going to talk about the principle of working from “back-to-front”, but let’s take a moment to put that all in context.
- Every project, no matter how big or small, has a “front” and a “back” when it comes to requirements process.
- If it’s a new product or process, you may or may not know exactly what the “back” (or the ‘end state’) looks like [this is why it’s caveated with “where and when possible”].
- Even if it’s a new product or process, not knowing is not an excuse to not try and envision an ‘end state’.
Why I find the end state to be potentially more important than the start. Many a project has started with what seems to be the most logical approach: what do we already have (current state analysis) and then what our needs are (future state analysis) and how to apply to that the current state to create what we want to have (future state definition). It’s such an easy 1-2-3, right? Here we are, here are the steps forward, and boom, there we will be.
The problem it is two-fold: 1) It is short-sighted (it is anchored to the current) and 2) it too often gets hashed out quickly at a high-level (it is ridiculously easy to move arrows and boxes around on workflow diagrams and visuals) and rarely is there the 1-2-3 done in a deep-dive fashion until we’re already in the technical specifications arena, or even in development.
The first part of the problem is not a dealbreaker – it presumes upon incremental change and the fact is that incremental changes tend to me more palatable to organizations. I won’t dig too deeply into that right now. I want to give my focus to the second part of the problem: the breakdown in detailed analysis when it’s lead from current state to future state, or in this case, from front to back.
It doesn’t always happen. You sometimes have project teams that are thorough and operate in such a strict waterfall fashion that not a single step in the actual build process will occur until even line has been crossed, and ever ‘i’ has been dotted. Those teams are few and far between and not for lack of trying but simply because the environments many of us exist in do not have the time or spend available to work in such a manner. In addition, personnel changes, priority changes, all of these forces are fighting against this. So, please don’t take this an indictment of intent, but a statement of reality.
Therefore, recognizing that, at a minimum, strong environmental forces can and do create situations in which thoroughness in specification bleeds off rather quickly, why does it make sense to start at the end state? The best way to answer that is to use a conceptual example.
I think of all systems as movement and acting on data. You could argue that’s a simplistic view, but when you really think about it, you have a task that must be done (the data processing) and you need to work on something to get it done (the data inbound) and when you’ve completed the work, you need proof of that (data outbound).
But don’t take my word for it, let’s try it against a random item – how about a working professional kitchen. How does this model fit?
Maybe you drop the word “data” and it makes better sense, but I’m going to leave it there because I want to walk through a specific software development item where the end state is a set of reports and the current state is a set of data points.
Nobody is perfect and everybody changes their mind. We don’t like to hear either of those statements, but when we develop details upfront, we like to believe “we’ve got it covered”. So, we may design a system with a set of fields and for it to be populated at a certain level of granularity and then decide that’s enough, let’s move forward. On the flip side, we may have an idea of what the end reports look like, the general sections, and we imagine that general sketch is enough and net-net, again, “we’ve got it covered”. We don’t, we never do.
The reality is that seeing is believing and the more we can make the “end state” as real as possible, the better we can elicit the supporting requirements. Why do I use the word supporting? Because while we often think of the model as top-down (i.e., we can’t need something outside of the initial definition) the reality is that the entire goal of the inbound process is to get to the outbound, and so, we should figure out what we need not by what we have but simply by what it is.
Let me state that again so that you can understand why the outbound, or the final state, is more important than the inbound. The purpose of bringing data in, however it gets into a “system”, and the purpose of processing that data, whatever processes that you may apply, is to create the outbound, whatever that may be. We start for the finish, so it is incredibly backwards to use the start to determine what the finish is.
This applies in all cases of software development, process changes, policy responses, meals that we cook, destinations that we choose to go, products that we build…it applies to everything.
Now, let’s go back to our example. The goal of this project is to daily generate and send a set of reports to a regulator for the purposes of being compliant with a regulatory rule. We start the project by assuming that all of that data can come from three systems and we decide to send it to one system for the purpose of collation and then distribution.
Best possible approach:
- Identify the systems which should have the data
- Find out all the fields the report needs to have
- Find out all of the acceptable formats for report submission
Believe it or not, and I’ve been on many a project, this is where the requirements process stops before the build starts. There is often an assumption that between the cross-net of identified systems, “we’ve got it covered”. And it’s assumed that since we know what fields / formats are wanted, “we’ve got it covered”. And budgets get allocated, resources get requisitioned, and work starts on building generic interfaces and in conjunction a hyper-detailed technical analyst starts to go through and confirm and—
Wait, there’s another system required. That field is in the list of available feeds from System A but it’s never populated. Or that field is a combination of fields which have different uses between System B and C and so, wait, we need to double back, or we coded it already but it’s all wrong and we wasted two weeks testing this, and then who approved this specification and—
Or, instead of starting, the pivotal “back-to-front” step could have been taken: do the detailed mapping exercise upfront with the full mock-up of the final report in one of the acceptable formats; after that, finalize the list of systems, finalize the technical specifications, and then go full out on resources to get the project moving forward.
Even so, even after pivotal step 4, things happen. Regulators change their minds, individual systems have their own roadmaps that sometimes steal the very things we need right out of grasp or transform them mid-flight during our work – that’s the chaotic nature of integrated systems, large organizations, and people. Yes, never forget, all of our problems, in some form or another, resolve down to being people problems.
And that’s okay, we’re not looking for perfect. The goal of the requirements process is always to make a best efforts approach and best efforts is based not just on solid top-down analysis but at least equally weighted bottoms-up analysis, or “back-to-front”, because just as many of us don’t like starting on journeys without a destination in mind, we shouldn’t design our projects in that same vein either, wouldn’t you agree?
In the last post on this topic, I’m going to talk about “fit-for-purpose”. Those may be my favorite words ever. See you tomorrow!