When Faucets Fail: Keys to Successfully Adopting New Tools

Example of Failed Adoption

In 1928, the wild cabbage cultivar known as broccoli was still new to the United States when E.B. White, channeling his inner scamp, penned his most famous caption for a cartoon in the New Yorker. The scene: An earnest mother admonishes her child to try the new vegetable, and the little girl, even in her tenderest youth, is positively awash with jaded cynicism. The runt, ruefully eyeing the plated abomination, seems weighted to the breaking point with all the hard-won wisdom that the better part of a decade can afford a kid. For this little girl has heard this song and dance before: the endless ruses of airplanes and choo choo trains and dessert. Not today, Mommy. To leave no doubt that she was onto mother's nefarious shenanigans, the daughter crisply replies:

"Well, I say it's spinach and I say the hell with it."

No doubt the child felt not only vindicated and proud of her own insight, but that she was doing everyone a service. The reality was that she would have no dessert and the hellspawn vegetable would sit there until it was finished. A bad experience for all involved.

New technology, like broccoli, promises to make our lives better, healthier, easier. Unfortunately, new tools don't have that reassuring patina of established use: the cultural acceptance, tribal knowledge, desktop shortcuts et al that tools develop over time. New tools (most especially in requirements, which often have many steps involving many people) may be abandoned for the old methods, which have no period of adjustment, yet also no prospect for improved experience. Even worse, initiative fatigue, a form of plain old change fatigue, can automatically short circuit a new technology.

I was recently browsing the "non-corporate press" section of the famous City Lights Bookstore in San Francisco and found a collection of old cartoons mercilessly lampooning a foolhardy new technology: the automobile. The message was clear, "My horse and buggy work just fine, thank you." It was a striking reminder that technology and change can turn the nicest of folks into braying jackasses that you couldn't move with a Chinook, let alone a carrot and stick. And no one is immune. Like Mr. White, we all have an inner scamp that has an inherent tendency to childishly reject change.

Even if the requirements for the tool have been vetted (hardly a forgone conclusion, even in departments that specialize in requirements management), you have to prepare the users for the change.

Keys to Successfully Adopting A New Requirement Tool.
Talk about your expectations for the new technology with new users. What are your specific objectives for use in this instance? Is it performance improvement, for example? How do you measure that? Here are some basic points you should address:

1. What are your specific conditions for disuse/rollback? (Are there conditions?)
2. Plan and set expectations for some frustration as natural (Don't promise silver bullets!)
3. Account for attention spans
4. Be realistic in your expectations
5. Develop an implementation plan
6. Develop a training plan
7. Establish success metrics
8. Identify subject matter experts and a communications plan

Frequency of Use, It’s Not Just a Use Case Template Item

Unfortunately, most of us know about projects that had low user adoption because users found them:

• Too slow.


• Too hard to learn how to use.


• Too inefficient to use.

How does this happen? Performance and usability requirements are missing or unfulfilled. Frequency of Use is part of the use case meta-data. A use case's frequency of use combined with number of users helps us determine the importance and benefit of writing performance, ease of learning, and ease of use requirements for it. (I’m assuming you have limited time and must prioritize which requirements you write).

Consider the following graph:

When you have a use case that falls in the upper right quadrant of the graph (B), high number of users-high frequency of use, the reward for optimizing usability and performance is high; it is compelling to write usability and performance requirements. For example, consider a use case that 10,000 people use 50 times a day. A 1 second difference in the performance has a potential impact of 17 hours per day. Further, if it is not obvious how to use the system, this will lead to training and/or frustration for 10,000 people.

When you’re in the lower left quadrant (C), low number of users-low frequency of use, the risk you incur by allowing developers to deliver suboptimal solutions is low. A feature used once a month by 5 people which performs 5 minutes slower than perhaps you had hoped has a potential cost of only 25 minutes per month.

As far as the other two quadrants, they are also strong contenders for usability and performance requirements. However, what you need from the development staff may differ by quadrant.

In the low number of users-high frequency of use quadrant (D), optimizing performance and ease of use may be compelling, but ease of learning how to use the feature may not have much benefit (e.g., training costs for a low number of users are low).

On the other hand, if you have a high number of users who perform a task infrequently (A), making it very easy to (re)learn may have a high reward, whereas sub-optimal performance and/or ease of use have a low user impact; users just don’t use it often enough to care if it is a little bit slow or takes a few extra clicks.

As you can see, the data helps you make the right decisions; frequency of use is not just a use case template item.

The Business Use Case

Use cases are an indispensible tool for capturing the behavioral requirements of a software product and many analysts employ them exclusively for that purpose. But use cases can also help describe the interaction between external entities and a business. And, there are some very good reasons to develop the business use cases that describe the business to be supported by your product.

The actors for business use cases are the suppliers and customers of the business. Money flows from the customers to the business and from the business to the suppliers. Customers exchange money for the ‘result of value’ that is the outcome of a business use case. For suppliers the result of value is the money they receive for delivering materials or services to the business.

One way to identify business use cases is to look for ‘business events’. The business reacts to things that happen in its external environment. One of the most obvious and important events is when a customer signals an intention to buy. Other events include: a customer submitting a payment or a supplier delivering a shipment. The business use case describes the step by step interaction between the actor and the business in much the same way a ‘product’ use case describes the interaction between an actor and the software product.

The real value of a business use case is that it allows (or forces) you to step back from your focus on the product and ask questions about what is happening from a business perspective when an event takes place. Software development projects are commonly initiated after a decision has been made to implement a software product. That makes sense. But, it can be a mistake to just accept a list of desired features or other artifacts as given. If you limit your focus to identifying the requirements of the product you eliminate the possibility of finding innovative ways to change the business.

Your project may be strictly defined by a project charter that does not allow for much business process innovation but if possible, spend some time upfront writing business use cases for the business process area your product will support. Think about the real problem to be solved or the opportunity to be captured. Document the business event that triggers each use case and the goal of the actor. Look for innovative ways for technology to deliver the desired result of value. Then, derive the product use cases and requirements from the business use cases.

Here’s an example of how this can work: One of the features desired for an accounts payable system was the ability to automatically match purchase orders with invoices before making payments to suppliers. Rather than write a product use case for invoice matching, the product team explored the business events and the goals of the actors. They were able to show that the supplier’s goal of getting paid and the business’s goal of paying only for what was ordered and received could be met by issuing payments to suppliers based on matching what was received with what was ordered. The business was able to negotiate cost savings with suppliers and no longer need to process invoices.

Indeed, Why Bother?

In his post Why Bother?, Mike A. used an interesting example. He questioned whether or not it was worth the effort to make a bed. He concluded it was. I disagree with one of his reasons, “it’s the right thing to do”. Here are two reasons to make the bed:

• To keep the sheets clean, when you are using the bed or bedroom for activities other than sleeping (such as a child playing on the bed).


• Because you find it sufficiently aesthetically pleasing to be worth the effort of making it.

How does this apply to requirements? We must always ask--what is the benefit of performing an action? Why are we doing this? Answers such as “because we always have” or “it’s the right thing” are insufficient. Why have we always done this? Why is it the right thing?

Controlling scope is one of the most valuable functions we provide and we must make sure there is value in everything we do. If we only use the bedroom for sleeping and don't care how it looks, it's not worth the effort to make the bed.

Scalability Requirements

Scalability is the ability of a system to grow in its capacity to meet the rising demand for its services offered. System scalability criteria could include the ability to accommodate increasing number of
· users,
· transactions per millisecond,
· Number of SQL statements that can run and provide results simultaneously.

I know many small and large applications having the scalability issues, mainly due to the lack of good requirements specifications, besides not having a sound architecture necessary for the scalability.

How important are the scalability requirements? Today, where the database sizes are growing left and right, the system performance expectations are growing equally rapidly. Keep in mind, no matter how efficient the hardware and the processers are, sound system architecture which can make optimal use of it is equally important. What I mean, for example is that the database architecture needs to be scalable to serve the anticipated increase in number of similar type of SQL queries submitted by online users, with no noticeable performance decrease and without any errors or holds or locks. On the other hand, it should accommodate the growing number of batch transactions without overstraining the batch processing time.

In a recently deployed software application that I know, a concept of event based triggers was implemented. Each event of change to the case data was recorded as a trigger, to be later consumed by batch processes. After the initial deployment of less than fifty thousand caseload, the application started generating swelling number of triggers day and night. It became a bottleneck and severely affected the performance. Finishing the batch processing cycle in time became a challenge! Within few months of operation, a breakdown occurred in the middle of batch processing. The system couldn’t manage the triggers explosion. Ironically, this system was touted as capable of holding a million of case load in its full capacity.

Incorrectly defined scalability requirements could adversely impact the software usage.

Scalability requirements could be broadly categorized based on the things such as user audiance, database usage, critical performance needs etc. For a highly user centric web application for example, the scalability requirement needs to be in terms of the concurrent number of users the system can support today, as well as in future, without letting the performance degrade. While these are categorized as the user scalability, the database scalability is the ability to respond to the increasing number of queries within the desired time concurrently vis-à-vis the ever growing database’s performance against the multi-transaction batch processing. The system scalability discusses requirements belonging to the server capabilities scalable to support the anticipated future number of open connections, the response time per user request etc.

The advantage of identifying scalability requirements early in the software life cycle is that it allows the architectural framework to become sound enough as the development proceeds. There are measures available to address the scalability, such as:
· efficient hardware resources to counter the user needs,
· database schema definitions, partitioning,
· complexity of the database queries and optimization techniques, etc.
However, it’s a difficult task to establish the benchmarks, and to simulate the test conditions to match them.

Scalability is an act of balance amongst the requirements, the software architecture, performance configurations and the choice of environments.

Tips for when you are missing the E in SME?

Today we’ll explore what you can do if your subject matter experts (SMEs) aren’t actually experts in the subject matter! I actually ran into this scenario a few years ago. I don’t want to actually describe the specific project to reveal anything about the organization or people it happened in, so I have made up an analogous project up instead. This particular project wasn’t actually for building software, it was for training. It turns out the point of this is still similar to working with SMEs in software.

My made-up project:

There was a project to create a training course for cruise ship pilots to
learn to use the ship’s technology to properly navigate shallow waters as they
approached land. Our subject matter experts were the ship’s pilots.

We tackled the project by doing our research on the science behind the technologies, in hopes that we would be able to speak the language of our SMEs. There was one popular book that all cruise ship pilots relied on to learn about it, so we read that book. We then headed out to gather information on what the specific technology was on the cruise ship. Then we set up meetings with our SMEs to interview them. All things said, we were given plenty of time with the ship’s experienced pilots, and we were able to actually get on the ship to look at the technology.

What was surprising to us was that in talking to the ship pilots about specifically how the technology on their ship worked, we learned they did not know. I guess that’s why we were building training for them! And when we talked about the science behind the technology, they were impressed – but mostly because they didn’t understand it. I was honestly shocked at how much they didn’t know. Certainly they weren’t crashing ships into the land too frequently, but it wasn’t clear if that was because of their intuition about how to navigate using the technology or because they had not run into a bad situation (pun intended!).

Again, I have to say this - this project was not about cruise ship pilots at all, and I mean no offense towards them!

So what can you do with no real SMEs?

Faced with the reality that our SMEs weren’t actually true experts, we couldn’t rely on them to provide the content for the training course. They could help us enough to validate that we were asking the right questions, but they just didn’t know all of the answers. That meant, we had to get creative about how to find the answers. The short answer to this problem – we had to become the SMEs! We weren’t really all that knowledgeable about ship piloting, and in fact, our only related experience was that some of us had been on cruises.

Here is what worked:

1. When we did ask the named-SMEs questions, we could not ask generic questions. We had to ask very specific questions, sometimes coming at it from 10 different directions and asking 10 different people, to ensure we had a trustworthy answer. Or more commonly, to realize we needed to do more research.


2. We had to get our hands on the technologies being trained. This is similar to requirements in software – you really do need to actually use the existing software. It adds invaluable context to what you are learning along the way.


3. We read any books or articles on the subject matter, particularly the theory behind it. It helped that we had backgrounds in science. This allowed us to connect the dots between the controls on the technology and the reason they worked. This was actually the most useful thing we did.


4. In dealing with the actual hardware, we had to call the manufacturers to get to the bottom of how the functionality worked. We read specs, and in some cases, we talked to the manufacturers engineers.

All in all, we think it was a success! Then again, this is a tricky thing to measure the success of, but that’s another post for another day. The ship pilots were certainly very excited by the training we built – they all felt like they were learning quite a bit from us on this topic.

What I can say for sure is that I look back at that project with fond memories, despite the unexpected SME challenges. It is part of why I enjoy consulting, in that I get to learn new subject matter with every project. And frankly, I know way more about “cruise ship navigation” than one could ever imagine!

Best Practices with Use Cases

This may be a lot of review for seasoned use case writers, but for those of you who are not as familiar with this requirements model, here are some best practices to consider. I assume you already know what a use case is, why you would want to use them, and the components that make up a proper use case. I've included some helpful links at the bottom of the post for more information.

Use a Template
A bit of a no-brainer, but I'm surprised at how many different use cases I see across projects at the same company (or even within the same project). Templates make your job easier, but even more importantly they make it easier for your readers.

Make Pre & Post Conditions Verifiable
Pre and Post Conditions should be written as testable statements. "User has logged in" is much clearer than "Log in". Also - if you have multiple conditions, they should be separated with an And or Or, as appropriate.

Adhere to Consistent Writing Standards
This is particularly important if multiple people are writing use cases on the same project - they should all use the same writing format, style, sentence structure, etc... Consider the following:

• Single statement per line
• Always have a subject - "User" or "System"
• Be concise - remember, use cases are not end requirements - you should be demonstrating the interaction between the system and user, but not detailed specifications
• Use an active voice

Do Not Include Design
Many use cases become less effective (or even un-readable) because the author attempts to put everything they can in the use case. Detailed specifications - particularly design elements such as button names - should not be in use cases unless there is a very good reason (and usually there is not).

Use an Appropriate Level of Detail
I can suggest some guidelines, but you will have to find what the "right" level of detail is for your own situations. Keep in mind these suggestions:

• Generally, use cases should be 10-15 steps in length
• If you find yourself repeating the same set of steps on multiple use cases, consider separating them out into their own use case
• If you have a use case with just a handful of steps, consider folding it into another use case(s)
• If you have many use cases that have essentially the same set of steps, make sure you are not writing different use cases for scenarios that describe the same interaction (e.g. if you have a use case for Purchase Music CD and Purchase DVD and they describe the same interactions, then you probably are capturing scenarios instead of unique use cases)
  

More Reading on Use Cases
Check out the following for more information:

• The Actor Factor
• Getting Started with Use Cases
• Levels of Abstraction
• Includes and Extends
• Agile Requirements and the Use Case Narrative
  

Style vs. Substance

In the world of requirements, we often focus totally on the substance of our creations - either in documents, diagrams, or requirements tools. There's no doubt that the substance is extremely important. After all, if you don't have the right content in the requirements, you're in for a ton of trouble.

The question is - if nobody can consume the information in your document, should you spend so much time making sure every detail is exactly right? The presentation of information in your requirements is, in many ways, just as important as the requirements themselves.

I think this is one of the reasons requirements management tools have big adoption issues is that they often miss out on this critical aspect of requirements documentation. Some tools provide reports or document generation, but they are usually less than pleasing to the eye.

I like to think of my requirements deliverables as projects within the project. Who is the audience? What do they want to do with the requirements? What do they need to get out of them? When looking at them in this light, you can think about the usability requirements for your requirements. As with software, these often get neglected when focusing totally on the 'functionality' of the requirements. When under a deadline, it can be especially hard to spend time thinking about these 'soft' requirements needs.

What can you do to have better 'style' in your requirements? There are tons of different techniques you can use to help make your requirements leap off of the screen. First of all, use of different fonts, font sizes, and colors in your requirements can help add emphasis and meaning to different sections. You might decide that all requirements are in Verdana, for example, while the body of the requirements is in Arial. This serves to emphasize what is a requirement vs. what isn't a requirement.

You can also use images and icons to convey meaning in the context of the requirements. The concept of sparklines can add a lot of punch to your deliverables and help get the intended meaning across.

Which is more important, style of substance? They're both important! Of course, style without substance will be totally ineffective, but substance without style can lead to different problems that are, in many ways, just as serious.

Getting to Yes - with Requirements!

Negotiation is an important part of getting any project right. It's rare for a project not to have any conflicting priorities or competing objectives. How do we handle this as business analysts? We typically have to work as negotiators. Negotiation is much more complex than "I want this, you want that, let's compromise". One can argue that in a compromise solution, everyone is losing something.

In "Getting to Yes", a classic book on Negotiation by Fisher, et al., we see alternatives to the pure "compromise solution".

http://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0140157352

The key to getting a solution that doesn't involve a losing compromise is to understand the interests, rather than the positions of the parties involved. Let's look at an example:

Positions -

Marc's Wife: I want to go to the mall.

Marc: I hate the mall. I don't want to go.

Interests -

Marc's wife's wants to pick up a purse that she knows is 50% off.

Marc doesn't hate the mall, he just doesn't want to spend 3 hours as a baggage handler and baby sitter.

You can see that negotiate a solution to this problem is much more achievable when we look at the interests over the positions.

Unfortunately, Marc's wife doesn't negotiate, so Marc usually goes to the mall. :)

The BABOK Ate My Laptop

I was doing some research to gather various industry opinions on a topic. So like any good requirements person, I thought I would check the BABOK! I headed out to the IIBA website to open it. I opened it online and remembered it was 329 pages, so I saved it to my hard drive, thinking that would be better for performance. And while it might have been “better”, it was far from usable.

I had to quickly jump into the document to get what I needed and close the PDF so that I could actually do other things on my laptop again. I checked my system resources and it was using 88% of my CPU and about ½ a gig of memory! And what should have taken about 2 minutes, took me 15 minutes.

This is my primary issue with the BABOK - usability. There may be fantastic information in it, but it’s so hard to find it, that I’m completely resistant to do so. The irony is that I think we all know how unusable 300 page requirements documents are. And we know how important it is to understand how your user will use a product in writing the requirements. Are we the shoemaker’s kids here? If you are going to have over 300 pages of “how to” data, surely there is a better representation of that than a flat file. For example, a navigable wiki-site would be more easy to use. It could be more of a tree-like implementation that allows varying views of the data and fast paths to get down into the details.

Now all of that said, I’d hate to just complain and not try to help fix the problem! The BABOK version 2 is coming out end of March for review, and so I hope to be able to provide my input if this has not been improved.

Do non-requirements exist? If so, where do they belong?

Every release cycle, after dev scopes the functional requirements against the release schedule, certain requirements fall out of scope for the release. These requirements are postponed until a future release, or potentially indefinitely. Part of the job of the product manager is to track what is implemented in a given release against what was originally specified by the user. But do statements about scope–including which requirements were implemented in the current release–belong in a requirements document?

Out-of-scope requirements are sometimes referred to as "non-requirements" or "future requirements", and some methodologies propose calling out these "non-requirements" in the functional requirements document. I have two issues with this practice. The first issue is semantic. The second is methodological. Both issues are very closely related, but I'll deal with the semantic issue first: I'm not entirely comfortable with the moniker "non-requirement". At worst, it sounds suspiciously like a term with no referent. At best, it sounds like something that doesn't belong in a requirements document. A requirements document is like a mini-universe. It is inhabited by requirements statements. Requirements are the things that make up the requirements document–much like the physical universe is comprised of physical things. So, I can't make sense of what a "non-requirement" in a requirements document would be anymore than I could make sense of a "non-thing" in the physical world. In short, it gives me existential angst thinking about what a "non-requirement" is (or is not)! Maybe if there were such things as "non-requirements" documents, then "non-requirements" would probably belong in them.

Secondly, the methodological point: A statement’s requirement-ness is binary: a statement is either a requirement or it is not. More specifically, a statement is a requirement if and only if the customer believes that the "System shall..." statement which describes the requirement is true or should be true. A requirements document is prescriptive–it describes what the system should do, not what the system can do in the current or upcoming release. Because of this, the requirements document should be more or less static after the user approves the document. Whether a statement is a requirement is not dependent on whether the requirement is implemented. Granted, there might be other factors which affect a statement's requirement-ness (such as another feature being implemented which makes the older requirement obsolete or nonsensical, or the user changes her mind), but not scope decisions. After all, the customer still likely believes that the "System shall..." statement is true or at least ought to be true–even if it will not be implemented in the next release (or any release at all, for that matter). So calling out out-of-scope requirements as "non-requirements" in a requirements document is not only disparaging to the customer, it is blatantly contradictory.

There is another good reason for not labeling things as "non-requirements" in a requirements document–it can become a maintenance nightmare. If you are constantly returning to the requirements document after every release to determine which requirements are in scope or out-of-scope, changing the status of a requirement to a "non-requirement" and back again, this is not only a lot of work, but confusing. Furthermore, it makes it difficult to generate a report which indicates which features were implemented in which release (unless this is also explicitly indicated in the requirements document, which is even more work).
So, the original problem is still unsolved–it's the end of the release and you need to know the difference between the requirements document and the implemented system. The requirements document cannot provide you with this information. What to do? The solution requires some upfront planning at the beginning of the release, but can be more valuable in the long run:

1. As soon as the user approves the requirements document, leave the functional requirements document alone. The requirements document should be a list of statements which the customer agrees is true. Don't label things as non-requirements. A better solution would be to continue to describe the statement as a "requirement", but ascribe a property to the requirement which indicates its scope (see below).


2. Manage all of the functional requirements in a tool. After performing your post-release gap analysis, identify the requirements which fell out of scope for the release, and label them appropriately (in-scope for release 1.x or out-of-scope for release 1.x, etc.). This maintains the statement's "requirement-ness", but adds a new attribute to the requirement. This provides you with much more information than calling out a statement as a "non-requirement", and is much easier to manage in the long run.


3. Periodically, review the requirements which have been out of scope and review them against the currently implemented system to determine whether they still make sense, and whether the user would still agree that they are requirements.

The Actors in your Requirements Model are Not Just Stick Figures

When gathering requirements there is a natural desire on part of both the requirements analyst and the subject matter expert to “just get on with it.” Both sides want to see models, use cases, functional requirements, non-functional requirements and all the myriad other artifacts that are created as a prelude to the actual creation of the software. In the process of doing this one thing that very often gets a short shift is properly identify and defining ALL the actors – the people who will actually be using the software that is being built.

This point hit home last week when I was surfing the web looking to see if I might be able to refinance my current home mortgage at a lower rate. On the one hand, with the current melt down of the housing market, they tell us that the sky is falling on our head. On the other hand, the Federal Reserve seems to be cutting rates every 30 minutes. So, I figured that this might be a good time to see if I could save some money with a better mortgage rate.

The first site I went to was one that advertises heavily on any number of television channels. They had gotten my attention and I figured this was as good a place as any to see if it was possible to shave a few points off my current rate.

To my dismay, I was confronted with a one page form that I was asked to fill out BEFORE I could even get an idea of what current rates might be. I looked around in other parts of the web site to see if the information I was looking for was available. No such luck. After a few minutes of this futility I gave up and moved on to another site that did not make me jump through hoops just to see what rates were.

I was mouthing some choice expletives under my breath about the sheer stupidity of the first site and how many potential customers they were losing this way when I started thinking as to whether this whole fiasco could have been avoided in the first place.

I could not have possibly been the only person who had come by their site looking for some information before delving deeper. And again, my behavior was not particularly unusual or radical as to be a corner condition. Many, if not most, potential customers were likely to first check out the rates before they spent fifteen minutes or more filling out an online form. So, how could a company that spends hundreds of thousands of dollars on advertising get something so basic as who is using their web site so wrong?

One possible answer might be that they did not spend enough time fleshing out their “actors.” In the above situation if you describe your “actors” as people who are applying for loan, then the rest of the site makes sense.

On the other hand, they are missing a whole lot of potential customers like me. People, who, while they might be in the market for a loan are not yet ready to apply for one. These are people who want to see what you have to offer before they start giving you a whole lot of personal information.

If this is indeed the case, a little bit of time spent up front in properly fleshing out their actors would have resulted in a radically different user experience and web site. If this is not the case and they are really looking only for people who want to apply for a loan, then their site should reflect clearly the kind of “actors” they are looking for. So, you either have missing requirements or actors who were not properly fleshed out. Not good whichever way you look at it. The sad part is that this is eminently avoidable with basic requirements methodology and techniques.

The next time you are starting off a project, spend some extra time up front properly identifying your actors. A few simple tips / questions you can use when identifying your actors.

1. Who else will use this software?
2. In what way are they different from the actors we have already identified?
3. Are there any other subject matter experts I need to be talking to who could identify other potential users of the software? In the above example, if you just spoke to the people who approved loans, you are likely to have just one actor identified – “borrowers.” However, spreading the net out wider to the Marketing or Sales Department could have netted you “browsers”. “agents”, “dealers”, etc. that someone in loan approvals did not even consider.
4. Try to be as precise as possible in describing your actors. For example, do not just identify your buyers as “customers.” Something more descriptive like “browsers”, “agents”, “bargain hunters”, “dealers”, etc. is a lot more useful.

Obvious? Yes. Common sense? Yes. Rocket science? No. Done always? Unfortunately no.

Resist the temptation to just get on with it and pay attention to your actors. Actors are real people not much different from you or me in many ways. So, if you are part of a project building software that is likely to get under your skin or drive you up the wall, chances are that you are not alone. Stop them.

You are not a stick figure. Nor are the actors in your requirements models.

Just Call Me "Grumpy"

I've been called a lot of things in my time, most of which I don't care to repeat here (OK, OK ... some people have called me nice things). I like to think of myself as a nice guy who has a good sense of humor, but I'm acutely aware of the fact that I can often be a grump, or a grumpus, or just plain grumpy. And while being grumpy doesn't always help get things accomplished, there are times when it can be an effective tool.

For example, this week I was part of a discussion about terminology. Well, at the beginning I was a part of the discussion ... and then the debate started to go in circles. The group was talking about the subject, but we weren't making any progress. As I like to say, we were spending a lot of time and energy working in a circle, but we weren't making any forward progress. So, I took a back seat. And then I got tired of riding in the back seat and put on my grumpy hat.

I sent a message that effectively said "jeez, quit talking about it -- pick a solution, explain it, and move forward using it consistently." Was it the best way to approach the situation? Was it even a good way to approach it? You could certainly argue either way, and I'd probably agree with either answer. What I found, though, is that my grumpy reply may have been just the thing that the team needed to get back on track.

I've found that teams often get off track by trying to find the answer, rather than an acceptable answer. People often call the situation "analysis paralysis" or "going down a rabbit hole" on a topic. The fact that we have so many terms to describe the condition suggests just how common it is. And in these situations, I prefer to take an approach that I've heard called "satisficing" -- finding a solution that's good enough. And in our business, we usually don't have enough information to pick the answer, but we have enough to be directionally correct and keep moving in a productive way.

Some might refer to this approach as simply lobbing a hand grenade into the fray and then watching things blow up. And sometimes it might turn out that way -- so I don't recommend this approach in all situations. However, when your team is stuck and doesn't recognize it, the time might be right for a grumpy interjection. Just make sure that your grump is a relatively gentle jolt, not a hand grenade.

After all, it'll help wake up Sleepy, it might pull Bashful out of his shell, it'll make Happy happy, and if anything goes wrong, you can always call Doc.

Requirements Contract vs Constitution

As a requirements consultant, I frequently find myself working with new clients. I don't always have a lot of context to their particular systems, projects, or problems. But I do occasionally find myself in a very familiar landscape: the adversarial relationship between IT and the Business. This is a situation that many analysts have seen repeatedly. Business doesn't trust IT to deliver what it wants. IT complains that Business doesn't know what it wants, so there's no way to deliver it. Familiar?

One common way to address this is by putting much more focus on requirements definition. We spec out the requirements in more and more detail, so that the business can know exactly what it is that it's getting. We treat the requirements document as a sacred contract to which IT can be held if they fail. And therein lies the problem. The requirements "contract" puts the onus on IT to deliver. IT fights hard to minimize what goes into the contract so that they can lower expectations. Business tries to squeeze as much into the contract as they can, since they figure that IT won't deliver anything that isn't in the contract. The contract becomes a document that defines (and perpetuates) the adversarial relationship between business and IT.

I prefer to think of requirements documents as a Constitution rather than a Contract. The document spells out the duties of both sides - business and IT. We recognize that it's a document that may need to be changed, and we decide on the mechanism for changing it. Most importantly, it's a document that is created and owned by BOTH the business and IT. This co-ownership of the document makes the document less of an artifact on which to base contention, and more of an artifact on which to base agreement.