Your Process Stakeholders Know a Lot Less than You Think

(Part Three in the series “Is Current State Modeling a Waste of Time?”)

In “What’s Your Process Intelligence Level?,” I explain that I’ve never worked with a Process Manager who had a comprehensive, in-depth, and completely accurate understanding of all the processes he/she was responsible for.  The same can usually be said about the people who perform those processes.  Sure, there are the so-called Subject Matter Experts (SMEs) who act and talk like they know more about the process than anyone else.  But in my experience, at the lowest level of process detail, most SME’s knew much less than what they thought they did.  They may know more than everyone else, but they still don’t know enough.

As for everyone else, the range and depth of process knowedge often varies widely from person-to-person.  And that is one of the root causes of process execution problems.  In other words, processes typically don’t fail because performers deliverately execute incorrectly.  Processes fail to execute properly because performers don’t completely understand:

(a.)    How the process is supposed to correctly execute
(b.)    What the performnce standards are for both the process and for them as individual performers

At first, few Process Managers want to believe that their department’s performers are that ignorant.  Or that there’s as much knowedge inconsistency as there actually is.  But a few simple exercises can quickly validate my assertion.

First, I suggest that the Process Manager attempt to verify/validate the SME’s knowledge.  And the SME I want him/her to challenge, is the SME the Process Manager holds in the highest regard.  I have the Process Manager engage in a one-on-one discussion where the Process Manager simply asks the SME to “walk me through” the process, in detail.  Every single time this exercise has been conducted, both the Process Manager and the SME have been surprised.  Never has an SME conducted an end-to-end process explaination without:

(a.)    Admitting they don’t know some (or many) important details
(b.)    Identifying or exposing persistent , but neglected, process execution problems
(c.)    The SME and Process Manager disagreeing on a few, if not many, process execution details

Next, I suggest that the Process Manager bring all process stakeholders together to attempt to verify the Process Manager’s assumption that everyone knows everything they should know about the process.  Have the SME lead the discussion.  Then, sit back and watch what happens.  See if the collective knowledge is thorough, complete, and accurate.  See if everyone, or at least the process performers, agree on everything.

Every time I’ve witnessed this approach, the Process Managers and Owners have been alarmingly surprised by the extent of knowledge gaps and lack of consistency of execution among process stakeholders.  Debate focuses on both the design of the process (how the process should execute) and the actual execution of the process.  And these discussions nearly always expose process problems that require immediate resolution.  At this point, emphasis begins to shift from dreaming about the utopian future state to doing whatever is necessary to stop the bleeding today.

What’s Your Process Intelligence Level?

(Part 2 in a series.)

In part one of this series, I listed eight reasons to justify modeling current state processes. I addressed an argument that often comes up when working on software development or process improvement projects.

A lot of times, organizations are in a big hurry to get moving with a solution.  They’re convinced that spending time on defining current state is a waste of time.  They believe they’ve already identified the root cause of their problems and want to hurry up and get started on what is usually a hastily decided solution.  And that, unfortunately, usually involves premature capital spending on technology.

In this rush to nirvana, it’s often a rush to fix the wrong thing. Thus, time and money is wasted, the real problem never gets solved, and often, the real problem is intensified.  In other words, they pay too much for something they should not have bought in the first place.

In situations where I’ve either been given the opportunity to focus on understanding the current state, or have been able to carve out time without impacting the project schedule, I’ve never worked with a manager who had a comprehensive, in-depth, and completely accurate understanding of all the processes they were responsible for.  At the very least, an in-depth understanding involves knowing:

•    Every discrete process within their management domain
•    The qualifiedly and quantifiable goals and objectives of each process
•    The qualifiedly and quantifiable inputs to, and outputs from, each process
•    The exact sequence of steps taken during the execution of each process
•    The specific resources (human and/or machine/computer) responsible for executing each step
•    The precise data that must flow within each step
•    The acceptable speed or rate of effort expended in the performance of each step

In some cases, I’ve worked with managers who knew a lot of the above information, but never have I worked with one who knew it all at the levels described above – at least at first.   In every case, it didn’t take long for the manager to realize that the first step in process improvement was to improve his understanding of the processes within his scope of responsibilities.  Many times, I’ve been initially engaged on a project to help a manager train his employees to improve their process execution competency.  In order to train the people, I needed to know the level of detail listed above.  When I’d begin to ask the manager for this information, that’s when we would both begin to realize how little the manager actually knew.  But to the credit of nearly every manager I’ve worked with, they were quick to admit and accept this knowledge gap, and equally as quick and enthusiastic about accepting personal responsibility for closing the gap.

If you’re a process manager and want a method for testing your own level of Process Intelligence, follow the instructions below.  While this quick self-test can’t compare to a full-blown, formal process management maturity assessment, it can give you an initial idea of the gap you’re facing.  If you do want to take it step further, simply use your favorite Internet search engine to search for the phrase, “process management maturity assessment” and you’ll find links to some assessments.  Or, you can follow this link to download a preliminary draft copy of my extensive process management assessment spreadsheet.

PROCESS INTELLIGENCE QUICK SELF-TEST:

a.     Time yourself on this one.  Take out a piece of paper, and as fast as you can, make a list of every process you’re responsible for.  If you can’t do it within about 15 second or less, that’s not good.
b.     Compare your list to the Process Classification Framework.  See how many you forget or should have more granularly identified.
c.     For each process you manage, list at least three specific, quantifiable measurements.  Allow yourself no more than 5-10 seconds for each process.
d.     For each of those measurements, define the specific situations, times and places where you deliberately and consistently measure them.
e.     Think back to your first day on the job as the process manager.  Did you begin measuring on Day One? If not, when did you start?  How does today’s performance compare to your Day One measurements?
f.      Within ten seconds, can you access all the current, accurate documentation that exists for all the processes you manage?  Do you think everyone else on the team can?  What makes you so sure?
g.     For each process, make a list of every single “data object” that participates in the process.
h.  Then, for each of these objects, list their individual elements.  (For example, an Invoice is a data object.  Elements of an Invoice are things like the Invoice number, the date, customer name, line item, price, discount terms, etc.).  Remember, most business processes involve data processing, which includes creating or inputting new data, recalling or reading stored (existing) data, changing or updating existing data, and sometimes, deleting data.

If you can breeze through the above list with ease and accuracy, you might just know enough about your processes to effectively start looking at the future state instead.  But that would only be if you don’t expose an existing process problem that requires an immediate, temporary (or permanent) resolution.  In any case, if you can’t breeze through the above list, there’s a strong probability that your “solution” will take a lot longer to realize, will cost much more than it should, and won’t likely fix the problem to the degree that you’d hoped for.

Is Current State Modeling a Waste of Time?

(Part One in a Series)

We live in a world of instant gratification and quick fixes.  In business, competitive pressure escalates relentlessly.  Money’s tight, time’s limited, and everyone’s impatient.  Regardless of the country or culture, business leaders’ prevailing attitude is to hurry up and get working on the fix.  Any action is better than no action.  We can afford any waste that results from our haste.  The end is certain to justify the means.  We’re too big to fail.  This time it’s different.

That’s why, when it comes to defining software requirements, or embarking on any type of process improvement initiative, focusing on today’s situation isn’t considered a good use of time or resources.  On nearly every project I’ve worked on, I encounter some resistance toward the work of defining the “as-is” or “current state” of processes.  Sometimes resistance comes from the project sponsors.  Sometimes it comes from process owners, process managers, and other subject matter experts (SMEs).  And sometimes it even comes from project managers and business analysts within the project team.

Too many process stakeholders think they know the full breadth and depth of current state issues and problems.  They think know how and why those problems started and why they persist.  Too many meetings, discussions, and E-mails have beaten the horse to death.  Many times, organizations are so sure of the problems – and the likely resolutions – that money has already been spent and resources have been deployed to start working on the resolution. All resources and activities are focused on the future, on the great vision of the fully-optimized future state.  Devoting any more time and effort to the current state is analysis paralysis.  “We’ve survived this long, we can survive a little while longer,” is the tragic belief.

However, the current state is always in a lot worse shape than anyone realizes – or might be brave enough to admit.  And it’s not likely to change any time soon, regardless of how aggressive the transition plan is.  Unless the entire organization (not just  a few change management “gurus”) has a lot of experience in successfully implementing large-scale business model or process changes,  the odds are stacked against this project finishing on-time, within budget, and with results closely meeting or exceeding expectations.  Realistically, few organizations can claim organizational change as a core competency.  Sadly, for most organizations, it’s a core incompetency.

From this perspective, it means that anytime is a good time to model the current state.  That’s because current state processes have problems currently causing customer dissatisfaction, waste and lost profitability.  Until the future state is reached, these problems will persist.  In reality, there are plenty of reasons to model current state.  In addition to simply being a means for identifying improvement opportunities in general, the following lists more reasons to justify defining, modeling, and documenting current state:

A.  You Know a Lot Less About the Current State than You Think You Do

B.  Your Process Stakeholders Know a Lot Less than You Give Them Credit For

C.  You Need to Stop the Bleeding Today

D.  You May Not Live to See the Future State

E.  You Need a Baseline for Measuring Progress and Return on Investment

F.  Process Stakeholders Need and Want a Change Roadmap

G.  Your Current State is the Future State

H.   Some Things Can’t be Changed – What Might They Be?

In subsequent posts, I’ll take an in-depth look at each of these reasons.

Too Much Process?

Awhile back, I was in the middle of qualifying and proposing a process improvement project for a large insurance company in the USA.  The company was looking to staff a team of process improvement specialists like myself.  As part of the proposal and selection process, the company had candidates “interview” with two or three different managers and at least one peer.   In this case, the peer was a Process Analyst in another division.

One of those questions posed to me by this “most senior” Process Analyst was, “Can there be too much process?”

At first, I thought it was a trick question. “Too much process WHAT?” is the first thing that popped in to my head.  Too much process definition?  Too much process design?  Too much process analysis?  Too much process measurement?  My instincts and experience told me not to challenge him too hard.  Most managers are woefully under-skilled at interviewing so I certainly don’t expect the average staff person to be any better.

I assumed he was really trying to ask me a set of questions.  Should every single business process be designed, executed, measured, and controlled?  Maybe he was trying to ask if all business processes require structure, focus, discipline, and accountability.  Or if there are any processes that can be allowed to execute inconsistently, without forethought of design, or with little or no risk of quality problems?

When I asked for clarification he struggled to re-phrase.  After fumbling a bit, he finally managed to communicate what he meant.  He was simply trying to ask if I thought some processes could be too rigidly designed, executed, and managed.

First, I told him that I think it’s difficult to quantify “too much” or “too rigid.”   Particularly if “just the right amount” (of rigidity) has yet to be quantified or put in context.   But to let him (and his dopey question) off the hook, I simply gave the age-old cop-out answer, “It depends.”

The less structured, focused, disciplined, and accountable an organization is, the more immature it is with regard to process management competency.  For these organizations, there is such a thing as “too much process.”  There’s no such thing in maturing organizations.

The Business Process Assessment Worksheet

One of the information products I’ve been working on is the Business Process Assessment Worksheet, an extensive, eleven-page tool for assessing a wide range of process management topics.  I started this worksheet while I was working on a process modeling and documentation project.  One day, as I was modeling a set of customer service and support processes, my Client’s project executive/sponsor asked me, “Compared to other Clients you’ve worked with, how would you compare our process management discipline?”

At first, I was tempted to quickly offer what could only be a subjective opinion.  My relationship with my Client was solid and I’m sure my opinion would have some credibility, but I wanted to give the executive an answer that was both quantitative and qualitative.   I knew of such things as process management capability maturity models but I felt that most of them were too high-level, generalized, and lacking in-depth measurement criteria.

I gave the executive copies of the process management capability maturity model documents I found on the Web, then began working on a more comprehensive assessment tool.  Unfortunately, the executive left my Client’s company before I had a chance to give it to him.  I really would have liked his feedback.

Recently, after reading the inspiring article, “Architecting the Social Information Experience,” by Andrea Ames and Alyson Riley (from The Society for Technical Communication’s Intercom magazine), I decided to try a social media experiment where I’d offer this worksheet as a free resource, possibly only for a limited time, with the hopes of receiving some feedback.  Someday, I may sell the worksheet.  But for now, I’ll give it away.

You can download a .pdf copy of the worksheet here.  Or, go to my Web site, www.process1st.com, and download it from the sidebar link.  If you’d like the original Excel spreadsheet version of the worksheet, please go to my Contact page on my Web site where you’ll see my E-mail address.  Just send me an E-mail and I’ll reply with the spreadsheet attached.  Remember, this offer is for a limited time only.  And I really need your feedback, so even if you only get the .pdf file, please E-mail me and let me know what you think about its value.

Process Assessment Worksheet

Process, Procedure or Policy?

I’m often asked, “What’s the difference between process and procedure?”  This question also comes up in discussions with other Business Process Management professionals.  In fact, when this question was raised in one of my LinkedIn process management groups, it sparked a vigorous debate among participants who, in general, seemed obsessed with coming up with the perfect, definitive, once-and-for-all answer.  Only one answer made any sense.  One bright commenter suggested it’s simply a matter of personal choice.

Googling “process vs. procedure,” gives you more than 65 million results.  That’s a lot of opinions.  Only one matters.  Pick your words, decide on definitions, make sure the words fit within and make relative sense in a deliberate, defined structure of definitions.  And be relentlessly consistent in the use of those words.

Below are my definitions:

Policy = the strategic “what”

Process = the higher-level tactical “how”

Procedure = the lower-level tactical “how”

Activity = a set or group of tasks, typically performed by one performer or entity; Procedures consist of Activities

Task = individual, discrete, instances of effort; a step performed in series;  Activities consist of a series of tasks

The point is, there is no industry standard definition for each of these words.  When it comes to your organization’s process modeling/documentation standard, what’s important is structure and consistency.   Make the effort to identify the words.  Develop reasonably logical definitions.  Openly and widely communicate those definitions.  And if you have any leadership responsibilities within the process modeling, documentation, or improvement initiative, be the leader who encourages everyone in the organization to stay disciplined in their consistent

Software Requirements Traceability and the Mythical SME

In my previous posts, I describe my reasoning on why I assert that the true origin of a software requirement is, and can ONLY be, a process.  Quite simply, software is a resource that participates in a process.  In general, there are only two broad categories of resources:  people and machines.  And from this perspective, the words “software” and “technology” are synonymous with “machines.”  What the software is required to accomplish during an activity or task within an activity (the lowest level of process decomposition), can be considered the ‘software requirement.’  Therefore, the origin/root/foundation of any ‘software requirement’ related to the execution of a process IS the process.

In my 20+ years in management and IT consulting I have seen dozens of software requirements documents and document sets.  Where traceability of software requirements is mandated, I have never once worked with an organization that collectively understood that the process is the origin of the requirement, not the person describing the process.  What they confuse is the simple construct that the process is the origin of the requirement,  but the person (“The Enlightener”) is the source of information that enlightened the business analysts about the needs of the process.

Managed requirements in these organizations wrongly focus on the content of the statement made, and the time and place it was made by the Enlightener.  When the Enlightener is the focus, this implies that one of the primary purposes for maintaining formal software requirements documentation is for defensive posterity  reasons, rather than as a QUALITY control tool.

The quality point isn’t a measure of how well someone documented what someone else said.  The quality point SHOULD BE on the accuracy and precision of the statement made.  In other words, the value of the requirement statement is realized ONLY by its validity.  What is commonly overlooked is the credibility of the person communicating the statement of need.  In other words, far too often, the credibility of the so-called Subject Matter Expert (SME) is taken for granted.  Rarely does the typical business analyst make any effort to verify the expertise of the SME.  This lack of a “check and balance” or verification/validation of the SME’s range, depth, and accuracy of knowledge (much less performance skill and experience) is a gross error that points to the ROOT CAUSE of most software development failures, disappointments, and budget busts.

In reality, a named SME is usually only the most knowledgeable person (about a process) in the organization.  To declare this person an “expert,” without any form of validation or verification of their expertise is imprudent and risky.  In other words, stop taking the SME’s word for it.  Instead, start focusing on verifying the details of the process.  That effort qualifies the expertise of the SME.

The diagram below illustrates the concept of the thesis of this blog and my previous three posts.  In Step 1, you see a BPMN diagram of the entire process, “Receive, Record, and Initially Respond to a Request for Service.”  In Step 2 a data flow task is isolated.  In this case, the task shows a need (or requirement of the process) to update a customer record.  Step 3 is the statement of the requirement.  The concept behind this simple illustration can be applied across the entire spectrum of software requirements.  With regard to the functional requirements of software, if a requirement can’t be traced to a data flow (create/read/update/delete) task, then what would its origin be?

The Need(s) of the PROCESS drives the Requirement(s) of the Software

The Credibility Gap in Software Requirements Traceability, Part 3

The true, accurate origin of a software requirement is a process.  Technically, requirements don’t originate from people who communicate “their” needs.  While I agree that a conversation or interview with a person or group of people (a.k.a. Subject Matter Experts) might be the first time and place where a Business Analyst (BA)  recognizes a need, the person is merely a proxy for the needs of the process(es) they participate in.   Yet, in spite of this obvious logic, the majority of requirements lists I’ve seen usually specify a communication event and/or a person as the origin or source of a software requirement.

The typical framework or approach to software requirements identification is to primarily rely on Subject Matter Experts (SMEs) to communicate software requirements.  Secondarily, a BA will attempt to find other information that they hope will enlighten their understanding of their customer’s (software user) needs.  But it’s rare for a BA to consciously structure their work using any sort of context as the foundation for their elicitation and research activities.  The problem of working without a context is that there’s little opportunity to measure and control the quality of the BA’s work.  In other words, there’s no quality control applied to the most critical phase of the software development lifecycle.

Without deliberate context, elicitation is unstructured.  However, in defense of the typical BA, he or she unknowingly, but certainly indeliberately, uses the processes the software will automate as the foundation or context for identifying software requirements.   And since it’s not formally recognized, it’s not formally used as the baseline for anything else in the execution or control of any process involved in the software development lifecycle.

The more effective and efficient approach is to base all functional requirements on the “needs” of processes.  Rather than begin the requirements identification process by asking SME’s, “What do you need?”, it’s better to first identify and define the processes the software will support through automation.  In general, software is used to speed up and/or improve the accuracy of creating, reading, counting, updating, or deleting discrete data elements.  In other words, speed and accuracy are what SMEs need.  But, without any context to work from, to expect any SME to thoroughly, completely, and accurately identify all the data that “flows” through a process is as unrealistic as it is negligent.

A more effective approach would be to first identify and define the processes the software will automate.  At this stage, SMEs can assist BAs in this effort.  The focus should be on the details of process execution, measurement, and control.  Speed and accuracy needs are much easier to identify in this context.  But more importantly, what both the BA and SME will likely identify is that most processes aren’t ready for effective automation.  In other words, they’re “broken” to begin with.

Broken can mean any of the following:

• The initial design was flawed
• Over time, the design has become logically obsolete
• The process doesn’t execute as designed
• The process executes inconsistently
• There are problems with process inputs
• There are problems with process outputs
• Etc., etc., etc.

The true, root cause of failure in nearly every software development effort can nearly always be directly attributed to the organization’s readiness, willingness, and ability to fix broken and mismanaged processes.

In an ideal world, the BA would work with SMEs to identify and define effective processes that can be made more efficient through automation.  Then, maybe, it might be useful to assemble a group of SMEs and other process stakeholders to clarify and confirm everyone’s understanding of the process.  From those efforts, data processing requirements become obvious.  Therefore, for the sake of software requirements traceability, it’s the process, not the communication event, that logically serves as the origin of the software requirement.

But if the process is broken to begin with, any attempt to automate is a waste of time and money.  Job #1 is to fix the process.  Unfortunately, the average BA has little knowledge, skill, or experience in the work of managing processes.  Nor, in most situations, is the BA qualified to teach a manager how to manage.  And the average manager is a reactionary fire-fighter who is rarely encouraged or rewarded to spend much time or effort on planning and organizing work – or in preventing the very problems they spend most of their time reacting to.

The Credibility Gap in Software Requirements Traceability, Part 2

One of the objectives within the scope of managing software requirements is to keep track of the “lifecycle” of discrete requirements.  The lifecycle generally includes the origination of the requirement, the evolution of the requirement, and the end, or elimination of the requirement.  There are plenty of prudent reasons for keeping track of requirement lifecycles, but that’s a subject for another post.  For now, I just want to focus on a significant problem regarding both the accuracy and methods used in identifying the origination of a requirement.   It points to the root cause of why so many organizations fail to thoroughly, completely, and accurately define software requirements.

In a typical organization, one of the first software requirements identification activities is to ask eventual users of the software what it is they think they “need” from the software.  The asking (elicitation) of needs/requirements is commonly accomplished through individual and group questions, interviews, and and other fact-finding communication events (i.e. Discovery Meetings, “JAD” Sessions, Brainstorming, etc.).  Unfortunately, few of these common elicitation techniques are explicitly and deliberately “grounded” in context or perspective.  If there is a context used, it’s usually either unrecognized or indirectly implied.

Without context, it’s nearly impossible to measure and manage the quality of elicitation efforts and results.  There’s no frame of reference to use to effectively validate communicated needs.  To make matters worse, the typcal organization’s approach unquestionably takes for granted the credibility of  the so-called Subject Matter Experts (SME).  The common practice is for Business Analysts (BAs) to interview SMEs, and from these interviews, compile a list of requirements.  But again, these interviews are rarely anchored in specific context.

This is what leads to my assertion that there is a serious credibility gap in the identification of the origin of a software requirement.  Without accurately identifying the true origin of a requirement, most subsequent requirement management and traceability efforts are wasted, if not altogether pointless.  What good is it to track something that started out wrong to begin with?

What most organizations wrongly identify as the origin of a requirement is a person and/or communication event.  Within the scope of requirements traceability, most organizations create some sort of record of the communication event.  The object of the elicitation (the proverbial SME), and the time and place of the elication result (response) are common elements of the record.

For example, a meeting (the communication event) was held today and an SME (a person) declared that “the system” should have a particular capability.  The average BA will create a posterity-focused record (too often just a row in a spreadsheet) to specify the meeting time and place and the SMEs declaration.   From a traceability perspective, that record is usually, but nonetheless inaccurately, considered the origin of a software requirement.

While it’s true that the declaration/statement may represent the first time and place the BA learns about a requirement, it only represents the origin of the BAs recognition of the requirement – not the origin of the need for the requirement.  That’s because, while the SME may believe he/she has a need/requirement from the software, the SME is only one of three categorical objects of the need.

Categorically, the organization, the process, and the process performer all have needs.  Therefore, for the sake of relevant traceability, the origin of the need technically begins with the organization’s strategic plan, which leads to the tactical implementation (processes) of the plan, and the performance of the participants of the processes.  Since software is simply a resource used by process participants to accomplish process activities and tasks, the origin of a software requirement should be one or more discrete processes or process tasks.

That’s why I insist that it is impossible to efficiently and effectively identify and define software requirements without FIRST thoroughly, completely, and accurately identifying and defining the processes the software will be developed to support.  And accuracy is highly unlikely to be realized without validating declarations, statements, and the accuracy of the “expertise” of so-called Subject Matter Experts.

In my next post, I’ll begin to connect the dots.  Within the context of traceability, I’ll discuss more about the relationship between process, Subject Matter Expert, and software requirements.  And I’ll begin to introduce a framework for effectively and efficiently managing and leveraging the knowledge, skill, and experience of SMEs in order to significantly improve the overall efficiency and effectiveness of the software development lifecycle and resulting solution.

The Credibility Gap in Software Requirements Traceability, Part 1

When it comes to the subject of software requirements traceability, most advice I’ve found is fundamentally wrong as it relates to (a) “the point of origin” of a requirement and, (b) the most useful and effective form/format for capturing requirement details.  Yes, I disagree with the most highly regarded and widely quoted “thought leader” on his logic and approach.  I believe he comes close to identifying the point of origin of a requirement, but is inaccurate nonetheless.  And I specifically disagree with his assertion that requirements are “…best captured in the form of use cases.”

Too often, the typical Business Analyst (BA) identifies requirements through individual and/or group interviews with so-called Subject Matter Experts (SME).  The questioning strategy and tactics usually involve a handful of open-ended questions.  The BA hopes the questions elicit verbose responses from the SMEs.  Then, somehow, the BA attempts to filter out useful information from the verboseness.  Once identified, that useful information is transformed into requirement statements.

This approach might be why Karl Wiegers claims[1] that the point of origin of a software requirement is a person or group of people. Since requirements are elicited from SMEs during communication events, such as individual or group interviews, I assume that’s why Wiegers asserts that the point of origin is a person who attended an elicitation/communication event.  While it’s true that the event may be the first time and place a BA identifies a requirement, it’s still not the true point of origin of a requirement.  The true, precise point of origin of a requirement is the process the person or persons participate in.

Focusing on the event and the person communicating the requirement suggests that the context of requirement identification is the communication event. Positioning the event as the foundation (context) of requirements offers little value or utility to the overall software development effort and the people who depend on good requirements to fulfill their role responsibilities.  Rather than helping software architects, programmers, testers, trainers, and supporters (administrators, help desk, etc.), the event context seems to primarily, if not only, serve the defensive needs of the BA.  When the project goes bad and requirements quality is blamed, the BA hopes to deflect blame to the person communicating the requirement.  The hope is to “prove” the problem has nothing to do with the BA’s unstructured, random, wing-it approach to elicitation and identification definition skills.  But rather, the BA hopes to suggest that, the person communicating the requirement wasn’t thorough, complete, or accurate enough.

In my next post, I’ll explain why and how the business process is the true point of origin and the most practical and robust context for requirements identification.  I’ll put the communication event and the people involved in the event into perspective.  Then, in subsequent posts, I’ll address the other issue I have with Wieger’s claim that the “best” form for capturing “user” requirements is the “use case.”  A single document or artifact is far from the “best” form/format.  And both the literal phrase, and his application of a “use case,” in the requirements phase are as confusing and ambiguous as they are inappropriate.

---

[1] Wiegers, Karl L., Process Impact, Karl Wiegers Describes 10 Requirements Traps to Avoid [WWW page]. URL http://www.processimpact.com/articles/reqtraps.html