Rich – Page 22 – In Search Of

Usage Scenarios

Posted on March 2, 2011Leave a comment

When you read requirements, do you ever wonder "How will an end user get value from this?" or "What does the user do with that information?" or "How does this detail matter in the big picture?"

You may be missing some usage scenarios. Usage scenarios tell you why the user is doing something. Where use cases start with an actor, and describe a series of actions required to complete some unit of work, the usage scenario, starts with a goal and an initiator, then details the actions and outcomes.

Case Study:
A few years ago I was on a project where we had a requirement to build a Cash Balances report. Our requirements described the format and content of the report, as well as the criteria for initiating the report. We had all the information we needed to build the report, but did not understand the reason the report was necessary, since the cash balances were displayed in several other places in the system. When the analyst went to ask the user about how the report was used, he wrote the following usage scenario:

In order to ensure portfolio managers can have updated cash positions at start of day <goal>, every morning when the reporting system is available <initiator>, the administrative user will run the "Cash Balances" report <action>, then input the cash balance for each account into the portfolio management system <action>.

Understanding: the goal of this usage scenario is "in Order To…" – which has little to do with the report that the user runs. Wouldn't an interface be better? Why would I even build a report? We learned that the cash balances that we were looking for actually came from a different system than we thought, and were only important for updating the portfolio system. We also learned that this manual update process took about 2 hours every day, and delayed the start of trading for the business unit.

Outcome: We built a fully automated interface, at 40% of the cost of the report, and saved .25 FTE effort ongoing in the business unit.

Understanding the context in which a feature or capability will be implemented is as important as understanding how the feature or capability will work. Requirements without an understanding of the business context in some manner are incomplete, and often lead to poor solutions.

In this case, we learned that the current business process could be significantly improved for less cost then supporting the existing process. This is an opportunity that would have been missed if we had not taken the time (2 hours) to understand the business context of the requirement.

Un-embellished Prose

Posted on March 1, 2011Leave a comment

In authoring software requirements, there is very little room for embellishing prose. When I read requirements that contain embellishments like adjectives or adverbs, I often think that each embellishment represents a requirement that has not been completely articulated.

For example, when I read a requirement that has words like "robust", "complete", "performant", "responsive", or my favorites "user friendly" and "intuitive", my instant reaction is "What do you mean by that?".

Every one of these words in a requirement, should be qualified by one or more requirements that explain what it means to be robust, performant, etc.

The greatest likelihood is that all project participants will have opinions about what these words mean, but without qualifying them, each person is allowed to believe that they understand, without actually agreeing or coming to consensus.

I challenge you to read your next requirements document, and circle all of the adjectives or adverbs, and ask "What did the author mean by that?" That might be a great way to start a review for a draft of software requirements.

Quotables

Posted on February 28, 2011Leave a comment

Over my career I have heard or said some amusing things…

“Fix like a car, or fix like a cat?” – John Merenkov, M.D.

When you fix a car you restore normal operation. When you fix a cat, you
prevent the “problem” from recurring. This may be accomplished by brutally
removing the source of the problem.

“You can lead a horse to water, but you may not be able to hold his face
under the surface.” -me

Sometimes people are stubborn, but drowning them may prove more difficult
than originally thought.

“If you show a man fire, he will be warm for a little while, but if you
light him on fire, he will be warm for the rest of his life.” –
unattributed

Sometime your goal is not the comfort of your team, but to induce a sense
of urgency at the risk of burning them out.

Objective perspective

Posted on February 24, 2011Leave a comment

Sometimes things that appear obvious when viewed from a distance are much
less so up close. Organizations and situations appear completely from the
inside than from the outside.

In order to become objective, one may need to gain some perspective. This
may require viewing from different sides and distances. It may require
putting yourself in someone else’s place.
You cannot consider your view as objective, until you have taken the time
to reconcile other points of view. When you have looked at all faces of
the situation that you can see, and your assessment is still valid then you
are approaching objectivity.

In this same way, don’t assume that others see things from your
perspective. When they don’t appear to agree with you, it may seem like
they are obstinate. They may simply have knowledge, experience, or insight
that allows them to see things that are hidden from your view. Start with
that assumption, and you may learn from them.

100% SLA Requirements

Posted on February 10, 2011Leave a comment

Sometimes our customers fail to understand the complexity of modern
technology.

Our customer expects a system that NEVER fails to complete some critical
process. The problem is that when that critical process reaches a certain
level of complexity, and/or has a single point of failure this is not a
feasible requirement.

We all recognize that people are imperfect, and that all man made products
are imperfect. Computer hardware and software are imperfect, whether we
built it or bought it matters not. The 100% SLA is not a feasible
requirement because it assumes perfection that cannot be achieved.

Sometimes failures come because things outside a process change without our
knowledge. These events can happen without our awareness and the faster we
detect them, the faster we resolve.

If the customer needs to ensure that his business process completes 100% of
the time, then he should define requirements to “detect and inform” process
failures, to feed a backstop process that corrects them.

If these failures are frequent, he should perform root cause analysis to
create new requirements to “harden” the process against future failures of
the same root cause.

This model provides a path to correct and another to improve. These paths
lead to maturity and quality, a 100% SLA is a path to disappointment and
frustration.

Direction, Trust, Feedback and Support

Posted on February 9, 2011Leave a comment

Most of us need these three things in some measure to be successful.
Leaders may need less than others, but also need to remember that those
that they are leading need these more than they do.

Most leaders will pick directions when none are provided, accept
forgiveness rather than permission, assume things are good based on
results, and ask for what is needful, network to build support for
initiatives and goals.

As leaders, we need to remember that those we are leading often need fairly
explicit direction, and permission before starting. They need to feel
trusted, and supported in order to accept responsibility.

We need to gauge how much of these things our team members need to be
comfortable, so that we can know when we are asking them to step out of
their comfort zone.

As leaders we may be graded by our customer, sponsor, and manager based on
our results, but we are graded by our teams according to how we have met
their individual needs for direction, trust, feedback, and support.

Impact Owners

Posted on February 8, 2011Leave a comment

How well do you own the impact of your actions, decisions, and
communications?

How frequently does the impact of our actions, decisions, and
communications not closely reflect our intentions?

You intend to partner with someone, but you end up alienating them instead.
You propose an aggressive schedule for a project to get people focused
quickly, but end up making commitments that you cannot deliver against.
You select a technology pattern that is common in the industry, and easy to
find resources to staff, but your organization fumbles the implementation
of the required infrastructure, delaying your project, and reducing the
perceived quality of your application.

These are examples of situations where your intentions did not match the
outcomes. How easily do you own the impact? How much easier is it to own
your intentions and assign the impact to others? How easy is it to blame
my colleague for being “difficult” to work with? To blame the project team
for the delivery failure? To blame the infrastructure team for your app
problems?

Leadership demands the trust of those you are leading. Whether you are
leading your reporting staff, a project team, or some other organization or
group, trust is required. Whether leading from a position of authority,
influence, knowledge, or savvy, trust is required. Leadership without
trust is a form of tyranny.

Leaders can be trusted when they are willing to own the impact along with
their intentions.

Specificity

Posted on February 4, 2011Leave a comment

Have you ever received a communication that raised more questions than it
answered?

A defect report that doesn’t describe expected result, only that the
feature is broken?

A review of a draft document with a sweeping condemnation of the content,
without example or recommendation of desired changes?

A project status report indicating that the project is experiencing some
issue, but no assessment of the impact of that issue or options to overcome
it?

In each of these examples there are some questions that recipients ask
themselves:

1) Why should I care? – the sender has not given me enough information to
assess the priority or urgency of a response.

2) What should I do? – the sender has not asked for any specific response.
How can I know that any response that I make will improve the situation.

3) Who is responsible? – especially if there are multiple recipients of the
communication, will someone else “take” this one?

The sender has (consciously or unconsciously) assigned all responsibility
to the recipient(s) for understanding the nature, impact priority, urgency,
cause, resolution. He has assigned all decision rights, and responsibility
for communication as well. This creates a “hot potato” where by “touching”
it I risk getting burned.

So when sending communications make sure you “speak” with enough speficity
to allow recipients to respond with confidence. Review your outbound
communication as if you were the recipient. What questions would this
raise for you? How would you respond?

Sooner

Posted on February 3, 2011Leave a comment

We all know that nine women cannot make a baby in one month.

When developing a project schedule, projected duration can be calculated as
estimated effort divided by full time equivalent resources multiplied by
some P or “rho” factor of productivity usually a fraction between six and
eight tenths.

According to this formula, given an unlimited supply of resources, any
project could be done tomorrow.

Of course in real life, we don’t usually have an unlimited supply of
resources. And there are costs of on boarding per resource, and
collaboration. So even if we did have unlimited supply, we probably would
fail some financial constraint in that staffing model.

But we need to look at the work itself to determine how many resources can
be employed concurrently to get work done in parallel. What real and
assumed dependencies require work to be done sequentially? What can
overlap to allow more resources to be productive at the same time? And
finally, what design decisions have we made that impose constraints on our
parallelism?

If sooner is important, then you may have to design this baby so that nine
women can make it in one month.

Vendor Candidates

Posted on February 3, 2011Leave a comment

When purchasing software for your business function, one must consider the following:

The software vendor has two value propositions:

1) The capabilities already built in the software product.
2) The vendor's capacity to add more capabilities over time.

These values must be compared to:

1) the prioritized requirements of your business function.
2a) your assessment of the vendor's capacity to add capabilities to their software product.
2b) the alignment of your business function with the vendor's target market.

These correlate to:

1) how little benefit you will likely realize during initial implementation.
2) how little benefit you will likely get from future releases of software product.

These are compared to:

1) how much it will cost you to purchase and implement the software.
2) how much it will cost you to maintain and upgrade the software over the lifetime of the application.

If you need to customize the product, or you need to pay the vendor extra to customize or develop capabilities so that you can accept the product, these change the cost/benefit ratio as well. A bird in the hand is worth 2 years worth of customization – by either you or the vendor.

If the product must be integrated with other systems in use at your company, those costs must be considered, as well as integration testing whenever either end of the integration changes.

In either case, whether you realize it or not, you are entering a partnership with the vendor, if the vendor doesn't act like a good partner, they probably won't be. Their corporate issues can become detrimental to your product implementation. Their staff choices can have tremendous impact on your ability to get your project done. Their vision for their product can easily move away from your companies goals. The cost of replacing the customized or integrated software will be higher than otherwise, and in all likelihood, the value delivery will be lower than expected.

Choose wisely, it pays to be careful, when making such decisions.