I started doing “business analysis” before I knew there was such a thing. We called it “Getting the requirements” or “Making sense of the requirements” or (often) “Who came up with the requirements (and the schedule)?”
I read books, went to conferences, thought a lot, and tried things out. A decade later, here’s how things typically go, when the client and I jell as a team, and I do it right, and it works.
By “works,” I mean the new (usually software-enabled) business process has been running for a while, and all stakeholders (including the makers and the person who paid the bill) are saying, “I’m glad we did that. That was worth more than it cost. Let’s do another one!”
So, here’s the candidate pattern.
- A would-be sponsor comes to me with an idea—a What—and a desired (Target) cost and deadline. Their idea is often either:
- Quite tangible—a screen sketch on a napkin–or even too tangible for this stage, i.e. wireframes from marketers and designers, or
- Quite abstract, except for one thing—“We need a mobile app! Yesterday!”
- Using questions and active listening, I help my would-be sponsor back up to Who and Why? Who’s going to use the new or changed product or process? Why would they want to do that? Why would you want them to do that? (Be careful with literal “Why.” It can feel confrontational).
- I then lead an examination of possible Whats that might satisfy the Whos and Whys, from four perspectives, using another pattern, the Merry-Go-Round™ :
- User Interface (UI)
- Data / Information, and
- Rules / Constraints.
- Most often from the Rules and Data, I infer additional Whos affected by the proposed What. Often they are not clearly beneficiaries. What additional changes, either part of the What, or alongside it, are needed to make them whole?
- I then see that an Estimate of cost and timeline is prepared, independent of the Target from #1. Target-Estimate-Commitment is another pattern I’ve observed and use.
- If there’s still too much uncertainty regarding the cost and benefit of the What to proceed, I then recommend where we should “buy a vowel” (a metaphor from the decades-long American game show, “Wheel of Fortune”), typically in one or more of Team, Technology, and Requirements.
- For Team, that means actually doing a bit of the work, end to end, to help them jell and get a sense of velocity.
- For Technology, that means a Proof of Concept, especially if we’re going to bring in something new, e.g. commercial software.
- For Requirements, that means further elicitiation and analysis of those portions of one or more of UI, Function, Data, & Rules where the cost / benefit sensitivity is greatest.
- I then provide decision support for a Commitment regarding the Essentials, Value-adds, and Delighters (Kano model) of the What, helping tie those back to Whos, their goals, and the associated costs and benefits (from the Estimate, with associated ranges and probabilities). I encourage variable-scope thinking. Resources usually are more tightly constrained than scope, and those constraints need protection from the remaining uncertainty (and there’s always more uncertainty than we would like, particularly if it’s potentially a high-impact What).
I have a typical Implementation pattern too, but that’s Out of Scope for now.
That’s how Business Analysis usually goes for me. Like all potentially robust patterns, it’s come from observation, not prescription. I didn’t read or decide, “This Is How It Goes.” Rather, I’ve observed, “This Is How It Usually Goes When It Works Well.”
I hope this candidate pattern works well for you, too. I believe it’s only a real pattern if it’s worked three or more times for three or more people. Please share your stories!
I’ll add two pictures when I get the time. That might make the pattern easier to see.
Agile has reached the early majority, and is running into trouble. At best, it doesn’t deliver what it’s capable of when the shackles are off. At worst, its failure feeds the political beast and vaccinates the organization against future change. “We tried that Agile nonsense, and it didn’t work! I Told You So™!”
Usually, Agile fails because organizations leave out an essential feedback loop.
- A governance process sets scope, schedule, and budget before initiating the Agile project, disabling the feedback of observed productivity (velocity) into a variable scope (the prioritized backlog); the team devolves to Cowboy Coding under the schedule pressure, and the product remains locked into a definition created when everyone was the most ignorant they will ever be,
- The team doesn’t do automated testing because they don’t know how or aren’t given time, disabling the feedback loop that controls technical debt; refactoring—as-needed redesign—is too risky, and productivity drops because the design is becoming incoherent,
- A defined process, outside the control of the Agile team, inhibits meaningful change based on retrospectives, which become glorified lessons-observed post-mortems instead of the lessons-applied process feedback loop they were meant to be, or
- Functional boundaries inhibit the frequent, regular evaluation of finished software by production SMEs and stakeholders in production-like environments, disabling the right-thing-done-right feedback loop.
Since early 2009 (four years at this writing), I’ve been using the metaphor of a house’s load-bearing walls to explain this. You can remodel Agile to suit your environment, but you can’t cut through a load-bearing wall, or it will fall down. In a match between personal will or political “realities” against the laws of physics, the smart money’s on the laws of physics, every time.
But I just read an article called Your HR Department can be hurting your company that caused me to say, “Maybe I’ve been missing a wall!” It’s not the gist of his article, but Don Herrmann makes this fascinating statement:
The real focus should be on leadership and for that a leadership expert is better suited. Notice I said leadership, a method of self directed empowerment that has sustainable accountability. I did not say leader, an others directed process relying on personal style that is not sustainable. Focusing on leadership ensures the long term strategic direction of the company is properly defined, navigated and accomplished. It survives the natural departure of leaders by ensuring a replicable and consistent conductor culture for the company.
This lack of what I’ll try calling “Peer Leadership” in established organizations explains some things I’ve experienced.
I frequently use Facilitated Requirements Workshops to elicit and analyze software requirements. The tensest moment for me is what I call “marker allergy.” I’ve just asked them to start writing user stories on 4×6 cards, using the markers in the middle of the table, and they’re just sitting there. And I’m wondering, “Are they allergic to markers or something?” They’ve always started writing, eventually, but meanwhile you could cut the tension in the room with a knife.
Or, we’ve just come out of a cycle start meeting with the sponsor/product owner with a set of user stories we’ve committed to, and we need to organize the work. They’re usually OK with putting together a WBS (Work Breakdown Structure), but when it comes to “Who Does What by When,” they all look at me. I’m the expert. I’m the “leader.” So I’m supposed to issue orders, and go down with the ship if need be, and I’m instead impersonating a mime. Eventually they get over it, but meanwhile you could cut the tension in the room with a knife.
Agile proponents talk a lot about self-organizing teams. I’ve spent all of my programming life in cultures like academic research and then start-up businesses where this was a given. The people were there in part because they couldn’t stand being told what to do! So I never really thought about self-organizing teams because that’s all I knew, until I started consulting in organizations with a management culture, and a “but I followed instructions” response when things go awry. It’s not their fault. It’s what they’ve been conditioned to do. They expect it, and there’s safety in it. Like Wallace, I can tell the sheep to “get yourselves organized down there,” but the results (after about 1:30 in the video) might not be as spectacular.
Perhaps Self-Organization or Peer Leadership is a fifth load-bearing wall, but one that needs to be installed, not merely protected like the others. Maybe team members used to big-M Management need explicit help with Peer Leadership. As a first draft, I’d include training and then coaching on how to:
- Size up and divide work,
- Estimate work, and help others do the same,
- Suggest first-draft ideas without being afraid of being wrong (or “getting a bad grade”–there’s a lot of PTSD left over from school. Just ask about the dreams),
- Be mindful of the “vibe” of the team and the work they’re producing,
- Identify strengths and weaknesses in self, others, and team, and change your mind when the evidence suggests (tell Malcolm Gladwell of Blink to go to blazes),
- Give feedback without becoming snarky, and
- Receive feedback (even snarky feedback) without becoming defensive, or, as Alan Godwin puts it, how to have Good Conflict, and
- How to prepare and give a simple briefing to a project sponsor without freaking out.
I’d then prep the sponsor on how to respond when things go awry (and they will). Keep the “Who’s in charge here?“ inside, and instead say, “What do you all plan to do differently now?” The experienced sponsor should use that experience to ask questions that help the team strengthen their plan, and resist the urge to pull an Al “I’m in charge here” Haig.
When people start to learn that they can’t hide behind a manager, but that they can take responsibility for their successes and failures, choose how to respond to the latter, and not get shamed and whacked by those with Authority, I’ll know that Peer Leadership is taking hold, and that our load-bearing walls are complete:
- Frequent inspection of running software in a (near-)production environment, by production people (functionality and usability feedback),
- Commitments based on actual velocity (productivity feedback),
- Automated testing (quality feedback),
- Regular retrospectives, resulting in action (process feedback), and, welcome to our new load-bearing wall,
- Peer leadership (team cohesion feedback).
Let’s try it out. Let me know how it goes!
I just read a WSJ article with the provocative title, “Sorry, College Grads, I Probably Won’t Hire You,” by Kirk McDonald, an accomplished Manhattan (not Kansas) digital media executive.
McDonald says that college grads lack “the ability to know enough about how these information systems work [to] be useful discussing them with others.” As an example, he throws out a client question about how long a project will take. As a remedy, he suggests spending the summer learning a little bit about one or two programming languages.
I wish I was being trolled, but I’m afraid I’m not. So here comes some advice of my own. Read more of this article »
London Transport passengers are exhorted to “Mind the Gap” between the platform and the train. The gap’s dangerous.
Likewise, I exhort business analysts to “Mind the Gap” between the Stated Requirements and the Implied Requirements. If you don’t, you’ve doomed your team to scope creep (more like scope avalanche) and probably a lot of budget and schedule pressure, and it won’t be the sponsor’s fault.
Minding the Gap—getting the implied requirements close enough—is the difference between a requirements order-taker and a Business Analyst.
So, how do you come up with requirements that no one’s stating?
I got the idea from Doug Rosenberg’s & Kendall Scott’s “Robustness Analysis” and Ellen Gottesdiener’s “Multi-Modeling.” I invented the Requirements Merry-Go-Round© as a way to explain it to others. I’ve since found it useful for the other things I’ve been writing about.
The original Merry-Go-Round© had only two horses—Function and Data.
You start with Function—say Use Cases or User Stories. Imagine some (very simplified) software to help pilots with flight planning and navigation. Functional requirement elicitation turns up:
- As a Pilot, I can select my departure, arrival, and alternate airports when preparing my flight plan.
- As a Pilot, I can enter the departure runway when I’m given my departure clearance.
- As a Pilot, I can enter the arrival approach to the arrival airport, and the assigned runway for landing at the arrival airport, when I’m assigned them by the air traffic controller.
- As a Pilot, I can select Voice Mode and the software will read me the waypoints, altitudes, and speeds for approach and landing.
Now, you head off to your lonely analyst’s garret (if you’re just learning) or let your Subject-Matter Experts (SMEs) take a break (if you’re a rock star) and head around to Data.
Everyone who makes software learns to look at the functional requirements for nouns: Airport, Flight Plan, Departure Runway, Arrival Approach, and Arrival Runway (I left out a few to keep it simpler). Then, sketch a logical data model. Then, re-convene your SMEs for some more elicitation.
The crafty BA will have noticed the sloppy use of sometimes “enter,” sometimes “select,” and found out that there are lists of Airports, and each Airport has a list of Runways, and each Runway has multiple Approaches.
Then, for each entity on the data model, ask three simple questions:
- Where do these data come from?
- What are all the possible uses for these data, and by whom?
- When and how are these data disposed of, and by whom?
You’re checking for CRUD—Create, Read, Update, and Delete. Data have to come from somewhere, and be read by someone.
The Pilot enters the Flight Plan. That’s one of the stated requirements. And s/he selects Airports, Runways, and Approaches. This we know.
But where do the lists of Airports, Runways, and Approaches come from?
“Oh, I guess we’ll need screens to enter and edit them.” Inspired by Ruby on Rails, modern application frameworks in many programming languages, and modern programmer tools like Microsoft’s Visual Studio now have “scaffolding;” when you create a data entity, it just creates plain-vanilla versions of these screens for you.
“We get them in a file from the government.” I’ll leave it to you to imagine what you would need to find out next!
“That’s a good question. I was hoping you could tell me. I’m just the marketing guy—I’ve been going around to air shows, talking to pilots about what they would like our software to do.” Someone, maybe you, now has a research project that could invalidate the feasibility of the whole project. Disaster averted.
To summarize, here’s how to Mind The Gap and find the requirements that no one’s mentioned:
- Elicit the functional requirements—the ones that are driving the project
- Infer a logical data model from the nouns in the functional requirements
- Infer the implied functional requirements from the entities in the logical data model using the CRUD check (Create, Read, Update, Delete
You’re not done, though. Your implied functional requirements are just a first draft for another round of elicitation. Involve additional subject-matter experts (SMEs) and expect a flow of additional information. If the implied requirements touch another part of the organization, you may have a new senior stakeholder. Get the sponsor’s help in developing that relationship and working out a potential change in the business requirements as well.
You still might not get a bonus though. Disaster averted is disaster disbelieved.
Until I started writing this series, the Requirements Merry-Go-Round© I drew on white boards had only User Interface, Function, and Data.
I added Business Rules because I know they’re important. But I’ve been putting off writing about them because I don’t know as much about the tools for eliciting, analyzing, and describing them as I feel I should. But that doesn’t mean I know nothing, so here are some simple tools that have worked well for me as I’ve developed requirements for smaller systems.
The Sponsor and primary Subject-Matter Experts (SMEs) are not likely to board the Merry-Go-Round at Business Rules, unless the system itself is about some kind of compliance. So you, the business analyst, have to ask the right questions to elicit them (draw them out). They’re often found near Data and Function, so ask these questions when working with those perspectives.
What exactly do people here mean when they say … ?
Read more of this article »
“You can get on anywhere you like, but you have to go around at least twice.”
So far I’ve been emphasizing where to get on the Requirements Merry-Go-Round©. Start with Function if it’s up to you, but if the Subject-Matter Experts (SMEs) you’re working with want to get on at Data or User Interface, let them.
(I’ll come back to Business Rules in a future post because I need to find some misplaced material from the last WI BADD® first.)
But the first trip around is just the beginning. Like any other kind of research—scientific, historical, journalistic—requirements work has two main activities, which the BABOK® calls Elicitation and Analysis. Elicitation is about sources. You’ve read about how to help your subject-matter experts (SMEs) talk about Function, Data, and User Interface, and how to use one to get them talking about the others. That’s Elicitation.
Analysis happens when you go back to your lonely garret and try to make sense of it all. It’s the second and third trip around the Merry-Go-Round. On the second trip, I “freeze-dry” everything, by transcribing and annotating my source material. This sounds fancy but it isn’t. Read more of this article »
Function is where you, the business analyst, want to start. Sometimes technically-minded Subject Matter Experts (SMEs) want to start at Data. But most often, especially if the software is customer-facing, your sponsors and SMEs will want to start with the User Interface. Marketing and design people will invariably start there (the really good ones will have developed Personas first). You may be bowled over by their enthusiasm and the amount of work they’ve already done. But, to quote Admiral Ackbar, “It’s a trap!” Read more of this article »
As a refresher, here’s the Requirements Merry-Go-Round©.
You can get on anywhere you like, but you have to go around at least twice. (I’ve double-ended the arrows since last week, because writing these has caused me to see that I change directions on the Merry-Go-Round a lot. No metaphor is perfect).
Most of the time, your sponsor or subject-matter expert (SME) will board at Function, because “being able to do things” is what the software is for. But sometimes, especially when enhancing or replacing an existing system, people will instead focus on all of the interesting things that are stored in the system—things I’ll loosely call “Data.”
I say “loosely” because the word “Data” can cause people to think too narrowly. It could be a document, a scan of a document, or an audio file of someone reading the document—you get the idea. So I usually use a word like Information, or even “What the system helps people work with.”
Modeling to talk about and describe Data
As with Function and its Use Cases and User Stories, the software profession has developed several ways to talk about Data. There are two main ones, Entity-Relationship (E-R) Diagrams and Class Diagrams (from UML, the Unified Modeling Language). Because these are also used by developers to talk about relational database design and object-oriented software design respectively, they have some very precise terminology and notation. Don’t go there when working with Sponsors or even SMEs (unless they’re pretty technical), and even then, try to stay out of the weeds.
One of my BA heroes, Ellen Gottesdiener, says, “You model requirements to facilitate communication.” Communication is like a freeway. When you overload it, it doesn’t just keep running at maximum capacity. It grinds to a complete halt.
The main things to model are
- Clumps of tightly related information, and
- The relationships between the clumps.
Precise definitions aren’t necessary, and can even get in the way at first.
Along with nearly everyone else, I use a boxes and lines. You can write attributes inside the box, label the relationships, and put some kind of markers on the relationship next to the boxes to indicate required, optional, and quantity.
UMLers like their numbers and asterisks and ERers like their crowsfeet. But what do Sponsors and SMEs like? Whatever you use, check that they understand. The best sign is when the SME corrects you. “There always has to be a Parent. Shouldn’t that be a one, not a zero?” That means you’re still communicating. You can tighten the lug nuts on the wheels of the truck later. The goal now is not to miss the fact that it’s pulling a trailer.
Eliciting Data from Function
How you talk about Data depends on where you got on the Merry-Go-Round.
If you started with Function, every BA knows to look at the nouns in the Function descriptions. In user-story style,
“A student completes an application to the program online. Students must provide information about at least one parent, because school policy requires a signed waiver from a parent or guardian, and the program needs a contact person on file in case of emergency.”
This follows the general,
“As a <role>, I can <do action> because <reason>” form of a user story, but in the way a subject matter expert might write it.
The initial data model might look like this:
The questions you ask are key. I might ask:
BA: Are there any other reasons why we need this parent/guardian information?
SME: “They also need someone to contact if the fees haven’t been paid.”
Huh. I just uncovered another User Story called “Someone Pays Student’s Fees.” If it’s not already on the list, I add it. It’s undoubtedly dragging more Data behind it. This is Merry-Go-Round thinking in action.
BA: Do the waiver person and the emergency-contact-person and the fee-paying person need to be the same person?
SME: “No, but they usually are.”
I would keep asking, next about adults who have more than one student in the program, but for this post, let’s move on.
Eliciting Data as the starting point
If you’re starting with Data because the first SME you talk to helped build the old system, they might even have a data model to show you. “Each Student has a one-to-many relationship with Parent.” Start a new model, though, like the one above.
Again, the questions are key. You use the model as a subject of conversation, and ideally you both add to it.
BA: Are there problems with this?
SME: “Yes, even though the table’s called Parent, they’re not always Parents. Sometimes they’re step-parents, or sometimes they’re legal guardians.”
BA: Does that matter?
SME: “Yes, school policy requires that there be a legal relationship between students and adults, for privacy and legal reasons.”
Here’s where more Merry-Go-Round thinking comes into play. If you’re thinking about requirements sequentially,
you might not pick up on that word “policy” as a Rule to talk about and understand, now. “That comes later,” or worse yet, that might be someone else’s interview. But ride around the Merry-Go-Round in your head and ask about that policy!
BA: Please tell me more about these privacy and legal reasons.
SME: “Well, I think it’s about the waiver form. Only a parent or legal guardian can sign one. You’ll have to talk to the Legal Department.”
BA: Who in Legal would be good to talk to about this?
SME: “Well, when we were sued that one time, Sally was over here wanting to know what we had on file and when it was entered.”
If Sally wasn’t on your list of people to talk to in Legal (if the plan even called for that), she’s on it now!
Often I’ll draw the Merry-Go-Round to show how I’m thinking. It often surfaces additional information.
SME: “Oh, now that I see that, another problem with the present system has to do with the fees. We record who pays the fees in a Payor table, and then things get out of whack because someone changes the Payor address and not the Parent/Guardian one, and then Development goes to do a mailing and they want an address list…”
Maybe I’m out of time or this SME doesn’t know anything more, but like someone clearing a mine field, I put a marker on the ones I suspect but didn’t confirm and remove or detonate. I’ve just heard about Fees and Payors and a stakeholder called Development and a mailing list.
More Merry-Go-Round thinking
Ellen Gottesdiener calls this type of merry-go-round thinking “Multi-Modeling.” You use one model to help with elicitation for the others.
Just like the nouns in Use Cases or User Stories often surface Data, the “because” clause often surfaces a policy or a rule. Don’t wait. Start that model now, visually, so you can get the SME thinking about it, too. (They can’t see what you’re writing in your notebook).
Likewise, when talking Data, ask your SME, “What are these data used for?” and “Where do they come from?” and “What problems arise because these data are stored like this?” It seems that most people like to talk about The Great Mailing-List Debacle of 2007. That often leads you to Rules and Functions—not all of them—but that doesn’t matter, because you’re going to go around the Merry-Go-Round at least twice, remember?
We, the people doing Business Analysis, and our Sponsor or Subject-Matter Experts (SMEs), will most frequently board the Requirements Merry-Go-Round© at Function. Why? Because it’s the best place to start if they don’t have a preference. And often their heads are there already, and they start the conversation with,
“I need it to do X.”
What we, with the BA hat, say next depends on who we’re supporting and what they’re trying to decide (Sponsor) or do (Developers).
Whom are we serving?
Sponsors must decide whether to fund this project or that, or prioritize this feature over that. They need an estimate of what each option is going to cost, and how it will help make money, save money, or keep them out of trouble with their boss or the authorities. This is about business requirements, policies, etc. They probably know. We just need to help them get there, by asking a purpose question, like “Why does it need to do X?”
Developers must implement software that does X correctly. They need to know the steps and rules for doing X using software. The subject matter experts certainly how X is done now and are usually delighted to tell us. We just need to help them describe all of the nooks and crannies, and then reconcile the different stories of how to do X with each other, while keeping current (X) and future (X’) states separate.
(I’ll have more to say about how things change whether we’re supporting Sponsors or Developers in a later post).
How do we talk about and describe Function?
This is not a new problem.
- We’ve had to talk about how to do X, and record it so we don’t forget, since the first time someone wrote software for someone else to use.
- And we’ve had to talk about why we need to do X and how much it will cost, since the first time someone decided to pay someone to write software for someone else.
So we have some proven-effective models for talking about and remembering Function: Use Cases and User Stories.
I’m assuming you already know something about Use Cases and User Stories. My purpose is to help you fit them together with the rest of the Requirements Merry-Go-Round©, User Interface, Data, and Rules, and provide some practical tips.
If you want to become a Use Case master, I highly recommend “Writing Effective Use Cases,” by Alistair Cockburn (CO-burn). You’ll learn how to work on different levels, analogous to the BABOK®’s Business, Stakeholder, and Solution. You’ll also learn how you can vary the depth of detail in your use cases to match the needs of the people performing the activities you’re supporting.
If you’re specifically working with User Stories, I’d turn to “User Stories Applied for Agile Software Development,” by Mike Cohn.
How do we elicit Function?
Especially if we are supporting Sponsor decisions, before a project is approved and funded, I highly recommend learning how to facilitate workshops. Ellen Gottesdiener literally wrote the book, “Requirements by Collaboration: Workshops for Defining needs.” (Ellen’s discussion of multi-modeling—using one model to check another—was one of two sources for the Requirements Merry-Go-Round© concept. I’ll introduce the other in the next week or two, when writing about Data).
Workshops are vital when perspectives, goals, and knowledge are diverse, dispersed, but interdependent in non-obvious ways. Eliciting business and first-draft stakeholder requirements for a system that will span functional boundaries in an organization is a classic case.
When supporting SME-to-developer communication, less structured interviews are fine, although I still prefer to interview with groups of 2-3 rather than individuals, and I always make sure to have visual modeling tools (index cards, sticky notes, markers, whiteboard, digital camera) available. The more they write and draw, and the less we write and draw, the better.
Use Cases and User Stories when transitioning to Agile
When talking to Use Case people who are transitioning to an Agile method, remove the “forget everything you ever knew” fear by describing User Stories as informal, low detail Use Cases, with the details to be worked out by the SMEs and developers, with the support of a BA with agile methods experience the first few times through. It’s not quite true that User Stories are a kind of Use Case (Cohn explains how they’re not) but people will pick that up better by example than by lecture.
The System Shall…
We will probably also encounter one-sentence “The system shall” requirements, written according to the IEEE 830-1998 Standard or some local mutation thereof. For a variety of reasons, which Cohn’s book gets into, these are very hard to work with, at least for Sponsors, SMEs, and Developers. Maybe they work well in other types of engineering, or in litigation.
If done well, they will be more or less grouped by something, often by function. More often, they’re just concatenated streams of consciousness with stilted grammar, and we, the wearers of the BA hat, will have to cut them up, organize them, cross-validate them, and organize them into groups corresponding to Function, Data, User Interface, and Rules, at the appropriate level (Business, Stakeholder, Solution). Then we will have something that the humans on our teams will find easier to work with.
If these one-liners are just how people are used to expressing their software needs, don’t fight it. When they see them transformed into Use Cases or User Stories, they usually heave a sigh of relief, particularly if they know they will have to do this again.
But if “The system shalls” are part of a contract (lucky us), we may also have to maintain traceability. I just use the numbering scheme they came with. If they are an un-numbered list in a Request for Proposals (RFP), I number them, in the order provided, and trace to that.
But what about this Merry-Go-Round?
If you’re wondering, “Isn’t he just writing about the same linear
process he said not to use last week?”
Thanks for reading, and I “salute your astute.”
The roundness starts next week (or the week after) when I write about Data, and cross-validating Data and Function to find gaps. I also have to write about the difference between Sponsor support and Developer support, and about the principle of diminishing returns. This might stretch beyond the customary four weeks!