Month: May 2016

The map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for it’s usefulness.

– Alfred Korzybski, Science and Sanity

 

Today abstraction is no longer that of the map, the double, the mirror, or the concept. Simulation is no longer that of a territory, a referential being or substance. It is the generation by models of a real without origin or reality: A hyperreal. The territory no longer precedes the map, nor does it survive it. It is nevertheless the map that precedes the territory—precession of simulacra—that engenders the territory.

– Jean Baudrillard, Simulacra and Simulation

 

And those who were seen dancing were thought to be insane by those who could not hear the music.

– Friedrich Nietzsche

 

More than anything else, what you are as a business analyst (or a human being in general) is a maker of maps, but maps of what? Surely not the map that will get you from Baltimore to Kalamazoo, or Bangladesh to Bonn. We are also not talking about a map of the star field above our heads, or the treasure maps we may have made as children. By map I mean a shared understanding of the way things work. Nature may not proceed or measure things the same way we do, but mathematics is a useful way of mapping events that occur in nature, just as our descriptions of things in language allow us to agree and communicate about what those events are. For us, a particular map may be a requirement, or a set of requirements. Or it may be the distance between what already exists and what it is being proposed.

Let’s say you have a new requirement. You have to define how to make a software application that does A and B also do C. First you have to identify what A, B and C are. What you know about A and B right off the bat is that the software does something when you prompt it to do something. You might not even know the intention behind what it does. You might enter a group of numbers, and those numbers get used in some formula and another number appears. B might present the numbers you entered, and the resulting number in a  graphical representation. You see what it does, but you have no idea why it’s doing what it’s doing. On the other hand, with C you may understand the why, the intention, but not yet have a model for how to go about satisfying that intention.

Every piece of code ever written has an intention and it may be safe to presume that every piece of code that will ever be written will have an intention, except for occasions of art or pure experimentation where someone may actually decide to create code without intention, but let us presume that at its very essence a piece of code is intention-based, that all coding is based on intention.

Functions A and B may be, respectively, an algorithm that estimates the number of eggs someone’s chickens lay that actually get sold, based on statistical expectation, and a visual representation of sold eggs versus investment of chicken feed. The new function, C, may be a cost analysis of feed to yield that takes into consideration typical seasonal increases and decreases in both the price of feed and egg purchases. It is a somewhat imagined translation of what it costs to produce an average egg, though an average egg doesn’t in truth exist, since some chickens will eat more and lay less, and others will eat less and lay more. There are also always unexpected, unaccounted for, influences. Perhaps the chickens toward the middle of the chicken coup are better shielded from the weather in the winter, and more prone to the heat during the summer, so there will be variations in how individual chickens produce based on feed consumption over time.

The key is the cost analysis is a very high level generalization of an imagined relationship among things in the world that are made into variables. I emphasize the word imagined here because it will come up over and over again in our work. Yes, there is a real relationship between how much someone is going to feed her chickens and how well they produce. If she doesn’t feed her chickens they will die. If she overfeeds them, there may be some other unwanted result. But there is no way outside a laboratory, where all other variables (at least those one can account for) can be controlled, to define quantitatively how many grains of feed produce a single, saleable, egg. There are too many factors. All your work in developing the algorithm is based on very limited data and a simplified view of the interrelations of things, the very flows of life that allow for egg-development as well as the forces in the market that may enable and inhibit their distribution. Such and algorithm may however be useful to the chicken farmer who needs to estimate how much money she needs to set aside for feed, and how much she will have leftover to rebuild part of her coup that was damaged during a storm last winter, or to expand her business further.

In another scenario, you may not even asked what the proportion of feed costs to egg yield are, but given the net of all expenses for the entire farm, including payroll, construction costs, machinery and maintenance, and so forth. An investor in the farm may not even want to know that level of detail, but perhaps only wants to know the cost to revenue relationship per year for this farm compared to other egg farms. He may include his investments in this chicken farm as part of an investment portfolio that he sells to other investors, who know nothing about the farm, but only the numerical results of the investments. He may want you to chop up the entire portfolio into investment units, or shares, that represent a part of the ownership or debt to the purchaser of the units.

As you get further away from the actual physical things happening in the world, you go higher and higher up in the levels of abstraction, and into a world of pure invention. That’s where most of us live. And it’s all maps of various kinds, some of seemingly actual things, and some of generalizations made of other maps and ideas that may assume that there are patterns to look out for, conspiracy theories of sorts about the way events may haphazardly coalesce and influence each other.

A user of these maps may even decide to design farms, or the very genetic make-up of the eggs themselves, to conform with an investment strategy. There may be a presumed need for additional resources, like water, that may belong to the community, but is required by the algorithm to optimize the strategy. It’s hard sometimes to decide whether we are talking about a benevolent innovation, or merely the deceptive fascination of the simulacra – ideas run wild and generating a misleading and destructive parallel world, which may have been innocent enough at the outset.

And so our map-making can have social and moral implications as well. Maybe not this piece of code you are working on, but perhaps the accumulated codes you have and will have worked on, the very way you work and address the problem-to-solution process, your style of working, since it is the habits that emerge from today’s efforts that shape the assumptions you and others will conform to tomorrow. We need to be awake to these effects. At least awake, if not actively shaping something useful and beneficial. As the artist Joseph Beuys repeatedly said, we are all artists, and by that he didn’t mean that we all were the makers of decorative and petty things. We all create, every day, just to keep ourselves alive and happy. Our every step produces another line on the map we’re not even aware we are creating, another set of shifts of habit, assumptions.

So as a generator of requirements documentation, you may not have the opportunity at every turn – since on a day-to-day basis it can come down pretty mundane stuff – to create something awesome and beautiful, but over time you have a choice to move, at least through the development of style, those habits of practice in a direction that helps to shape a culture we can love and be happy to leave for others.

 

 

 

---

You hear all kinds of questions about what project methodology to use, and in what situation. Should it be Agile, Waterfall? How does one approach the various project roles within each? What about documentation, is there an approved standard? Is there an approved standard for anything?

Experience keeps telling me that the answer to all of these questions come out of the context we are working in. For instance, my organization tends to manage projects via a Waterfall approach, as sort of an umbrella organizing function over projects. This is because we contract for large, often multi-year software implementations that involve custom enhancements to products, as well as a great deal of integration work. We need to get the project pretty well defined upfront for contractual purposes. Then under the umbrella there may be one or more Agile teams doing their work on separate streams, while some business analysts are working off to the side, writing interface specifications, training, and gathering further requirements, handing things off to developers, and so forth. And even under the umbrella of a Waterfall methodology, there are constant iterations to gathering specifications, writing documentation, specification review, development, testing, reviewing the results, and often rewriting specifications based on those results.

There are always conflicting needs. First of all our clients need to know what they are paying for, how much they are paying, before committing to a project, and at the same time there are also many unknowns. You have to get good at what you’re doing by doing it, and often there are going to be mistakes. Part of the reason why is that the it that you have to get good at, in order to have mastery of the entire process, is not a thing, but only an idea. At best, it’s a moving target.

This is why you need to hone certain instincts, so that you become sensitive to the needs, not only of the client, but to the needs of the entire project, or just your little sliver of it. You have to know when to stop going in one direction, and turn a corner, or start over from the beginning.

There’s a popular assumption that failure is due to lack of organization, or failure is due to people not knowing what they’re doing. Both of those assumptions are false. Very often the cause of failure is over-organization and lack of flexibility. And even more often the cause of failure is an inability to admit that one is always working in the dark, that we don’t really know what we are doing until we do it. These two things work hand-in-hand – inflexibility is often due to believing you know what needs to be done and the best way to do it when you don’t, or perhaps faking it too hard.

Pretending one knows what one is doing, and relying too much on the scaffolding (i.e. project management methodologies, and other things they teach you in certification programs) instead of the process of discovering what the requirements are and creating the solutions along the way, is more conducive to producing content for primetime sitcoms than it is to actually getting the work done.

Don’t get me wrong – I’m glad the scaffolding is there. When I’m working in a BA role, I’m often so deep in the weeds, into hair-splitting details of a piece of code I’m trying to design, that it’s good to know there’s someone there looking over the whole thing from above, with her map (project plan) of the entire battlefield, so I don’t have to keep track of the next thing I need to do, and the sequence of things, and who the best people are to talk to for that next particular bit of business. But at the same time, I am giving my feedback, and we are rescheduling things, splitting things into multiple tasks, and recombining things where new synergies have been discovered. A project is a living thing, made up of living parts, and like all living things is full of surprises.

So apart from the requirements one needs to meet, that make up the project – i.e. what gets delivered to the client – there are the meta-requirements of the project itself, its incremental discovering what it is, just like all of us.