"[W]e really can't understand what is happening on the project without taking into account the side games that people are playing at the same time."
^{Better Software Magazine, August 2007, pg. 33}

The concept here is that everybody, including and especially stakeholders, use "game boards" that can be predicted using activity theory. As an example, a project sponsor may be (quoting again) "…playing on game boards centered around career growth, relationships with peers, and relationships with other communities (user communities, business partners, etc.). The outcome of the game called build system X is evaluated by the sponsor with respect to how his position changes on all those other game boards."

My question for y'all is, "How often do we move beyond the things we need to know about the project at hand, to understanding what it is that makes our stakeholders tick?"

Thoughts?

What, exactly, is a "model?" I'm not talking about this or this . I mean, when BAs are discussing "models" ("logical data models," "process models"), what exactly do they mean?

Is it graphical? How many times have you been referred to a "modeling tool" to create a representation of data?

Is it textual? I've never heard of anybody referring to MS Word as a modeling tool…

Here's an example of the impact of my private quandary:

When somebody is required to deliver a "model" of the data related to a project, do they have any basic idea what that should look like if it were placed in a lineup? Would they panic, not knowing what to deliver? Are they afraid, very afraid???

Surely there must be some consensus somewhere… 

I know! I'll look!!

(Sometime later:)

I looked here; I looked there; I looked everywhere. Sigh. No clear, unambiguous consensus.

But I found a couple of clues. First of all is the use of the word "abstract" in so many of the definitions.  I think that the use of the word "abstract" is useful. I've noticed something interesting about data: you can't really "see" it. You can see representations of it (like reports, a GUI displaying it, or even a table listing), but you can't really see it, unless of course you elect to try direct examination of the storage media via a scanning electron microscope, which I don't recommend for BA standard practice. It's way too distracting from the goal.

Which leads me to my second observation:

The use of the word "representation" in some of the definitions.

After thinking about it for a bit, it appeared to me that a great definition for the word "model," at least as used by BAs in the performance of their jobs, could be:

"Any visual representation of an abstract concept that is useful for communicating the realities of the project related to the representation."

This definition would prescribe, then, the use of either graphical, textual or both methods for this purpose. But, note also, the use of the word "communicate." This is at the core of the need. If the delivery method is not right for the audience, then the "model" fails the test of the definition.

No matter how cool the picture, if the target audience doesn't grasp the reality of the subject, then it's worthless. 

No? Feel free to correct me.

According to webopedia.com and Wikipedia , the acronym variously stands for “System Development Life Cycle” (or “System Design Life Cycle”) in most cases, and “Systems Development Life Cycle” by the DOJ (why lawyers have any say in this, I don’t know).

Note the singular “System” in most uses (Wikipedia has a re-direct to the plural from the singular, so I presume they are considered to be of equal validity for that reference). Most modern, rapid/agile/fast/whatever methodology references I could find (see here , here and here for examples) refer to it in the singular, although that’s certainly not univerally true (hit the link to the last example above for a real quandary). There are a ton of other, software-focused sites that call it, predictably, the “Software Development Life Cycle.”

I couldn’t find the Yourdon book to verify his Delphinic definition of the acronym. OK, actually: I threw up my hands in dismay after so many un-attributed opinions. I will probably never really care whether Yourdon refers to it in the singular or plural. Based upon what I can find, my gut says that “System” is conversationally interchangeable with “Systems” in most general-purpose cases.

In other words, people call it what they want.

Wait! What about “PLC” (Project Life Cycle)? Isn’t that valid, too? I mean, what if there is/are no “System(s)” involved? Or software? Don’t BAs just care about the “Project?”

I think you get my drift.  To cut to the chase:  There’s no substitute for a good glossary. No matter how many arguments other people are having about terms, if they are defined in your company’s glossary for all to see, then you can do business.

Isn’t that what it’s all about? Correct me if I’m wrong…