Disambiguator

The Business Analyst (BA) adds clarity necessary for projects to pass smoothly from one approval gate to the next. Without this clarity in the form of proper goals, scoping, and ROI the project can get hung up along the way — and possibly sit on the shelf for years. I was added to a project recently that was “in the making” for over six years. There was plenty of “how” material gathered but not much on “why.” The project was missing a business case in general and the ROI (or Cost Benefit Analysis as they called) in particular.

But how do you throw a trained BA into the mix without telling everyone else [overtly] that they were not able to succeed? When a BA is introduced late in the game, the customer may be reluctant or even angry about working with him/her. The customer may feel that they are wasting time going over things that others have covered.

Gina Trapani of Smarterware.org posted this question to her Twitter followers:
          What’s the best Project Management software?
Here is a summary of the results:

See the detailed responses in her May 2009 post.

Your earliest training probably includes the admonition, “Never say ‘never’.” If you do, surely the event you are railing against will then happen… or so the theory goes. You were also cautioned to avoid the use of superlatives because they make you seem dogmatic or arrogant. This may be good advice for everyday speech and writing but there is a place where superlatives are not only helpful but seem right at home… in a Requirements Specification document.

Consider these two statements from a software specification:

A. The repair estimate may not exceed 40% of the book value of the vehicle.
B. The repair estimate may never exceed 40% of the book value of the vehicle.

These two rule statements (software requirements) are almost identical. Only one word is different: “not” vs. “never.” Do the two sentences mean the same thing? Logically, yes. So what’s the difference? The difference is that a business person reading (or hearing) the rule might skim past the word “not” but is likely to pause at the word “never.” The word “never” is normally avoided in our speech and writing and this makes it useful in evoking a reaction from the reader. Why? The reader in their role as a reviewer/approver wants to make sure all of the statements are correct. The presence of the word “never” instead of the more casually used word “not” will get their attention. They will, in effect, be challenged by it. “Never?” their mind will say. “Not ever, under any circumstance?” It is just such a challenge that writers of requirements want to pose. Why? Because even one exception to a stated business rule, if found late in a software project, can cause a big jump in the project cost.

We want to avoid the situation where, during customer testing, they tell us that the software won’t let them do something important. When we point out the rule they gave us (“A” above), they respond with, “Well, that’s true ALMOST all of the time.” Gotcha!

The word “always” can serve the same useful purpose. Here are two more examples:

A. A patient x-ray must be delivered within one business day.
B. A patient x-ray must always be delivered within one business day.

Again, these two statements are logically equivalent. However, the presence of “always” will draw attention and challenge the reader to approve the stronger assertion of this now dogmatic sentence. Their anti-superlative flag will go up and say, “Does it really have to arrive in one business day or are we really saying that it should be delivered as fast as possible within other cost constraints?”

Let’s face it… reading a requirements document can get pretty dry. Use words like “always” and “never” to wake up your readers and goad them into corrective action. For real entertainment, throw in the word “sometimes” and see what happens. I’ll bet you get a flurry of “always” or “never” in response!

You’re dreaming about a new software purchase and you think to yourself, “I don’t want to miss out on any important features.” So you scan vendor literature and websites for ideas… then load up the list of items you’d like to have with all the best stuff, right?

This is a bad idea for several reasons.

First, suppliers can tell a wishlist from a solid requirements document. The most likely reaction is that your wishlist will be ignored. “But why?” you wonder. The reason is very practical. Responding to a request for proposal (RFP) takes time and effort. Suppliers know that they are going to meet competition, so they want to put their best foot forward. This requires time and expertise to understand the requirements and tailor their proposal to fit your needs. But when your needs are wide-ranging and fuzzy (as are most wishlists), they know that you are “just fishing” and not a serious buyer. They simply won’t invest their time on what they view as a low-yield opportunity.

Second, you can drown yourself in supplier questions. Once you open the gate with a poorly defined request for proposal, the clarifying questions will come flooding in. How will you handle them? The questions will differ from one supplier to the next, so everyone you talk to will get a little different version of your needs. The result is a mixed basket of fruit as explained in the next point.

Third, the suppliers who *do* bother to respond will respond with apples, oranges, and even some grapefruit. Since the requirements are not clear and tight, the proposals that you get back will suffer from the same fuzziness and wide-ranging malady that the wishlist has. The result is wasted time on everyone’s part.

If what you are trying to do is educate yourself on possible solutions, the proper approach is to issue a request for information (RFI). This offers vendors an opportunity to send you their standard brochures and marketing material, along with ballpark pricing so that you can “get a feel” for the solutions.

Finally, any consultants lurking in the wings who *could* offer targeted expertise and potentially save you a ton of time will not react to your wishlist for the same reason as the suppliers… they recognize the amateur do-it-yourself approach and they don’t want to get involved with companies who shortcut important processes. As a result you miss out on expert advice and the steerage that comes from hard-won experience.

Sometimes we get so caught up in the details of complex things that we forget where we’re going. Stephen Covey has it right when he exhorts us to begin with the end in mind. Try thinking of a software project (or any project for that matter) this way the next time you have to come up with a project plan or build an estimate. It will make it harder to leave out an important step.

When the dust settles in our perfect software delivery world…

* The organization is advanced by achieving its automation business goals

Which can only happen if…

* System users are highly productive

Before that can be true…

* Trainers educate users

And before they have anything to train on…

* IT deploys the release

Which can’t happen until…

* Testers verify correctness

But not before…

* Developers code each feature in a phase

Which is preceded by…

* Designers specify how each feature should look and behave

Who get their marching orders from…

* Project Manager launches phase X development

Who got permission from…

* Stakeholders authorize phase X

Because he/she did this…

* Project Manager presents phase X plan to stakeholders

Using reasonable numbers from…

* Joint development team estimates phase X work

Having a defined scope of work because…

* Team prioritizes features and divides them into phases

Because this process went well…

* Analyst elicits desired features for each role

But only after gathering this list…

* Analyst identifies the audiences (roles) to be satisfied

Who was launched by these folks…

* Stakeholders approve requirements gathering phase

Because this person made the business case…

* Project manager works with analyst, designer, and lead developer to prove the feasibility and ROI of the project as a whole

And all because someone had a brilliant idea…

* Stakeholders envision a project and theoretical ROI

If you turn this list upside down and use only the bullets, you’ll have a pretty good skeleton for your next software project. Don’t forget the cake and ice cream celebration at the end (or was it the beginning?).

What happens to a project that faces unforeseen trouble when it does not have a blueprint? Read Michael’s article to find out…

Apple, Facebook, The Washington Post, and others all think we can put a stake through IE6.

How ’bout you?

========================================

When smoker lights another cigarette from the one they are already smoking, we call it chain-smoking. A similar phenomenon occurs in meetings. I’m sure you’ve seen it…

Bob asks a question and discussion begins. The discussion stimulates Sarah to pose another question, so she does. This question and the ensuing discussion causes Brian to think of an unanswered question he has about a related, but different problem.

Unless someone is recording this meeting as a brainstorming session, it has descended into a more or less chaotic group event. This can be very costly.

Organizations have meetings to accomplish specific goals (or they should). These goals usually don’t include having a room full of people satisfy their curiosity. Chain-questions cause rapid subject shifts, which lose some of the listeners and perhaps even the meeting organizer. The effect can be that attendees get a mental version of “tennis neck.” If notes are being taken (and they should be), it’s very difficult to track the group’s decisions, if any are being made.

The meeting facilitator must maintain a reasonable pace and focus, if the meeting is to be effective. Encourage participants to jot down questions and additional thoughts that are not on the topic being discussed. Then, when there is a lull in the conversation, a new topic can be introduced and everyone can track along with the new discussion.

In the third article in this series, we explore the pros and cons of renting vs. buying software. If you track on the popular tech stories about software-as-a-service (SaaS), you might think that “everyone is doing it.” Turns out that there are distinct advantages and disadvantages to this approach.

Read the article here.

In the second stage of growth, islands of information appear causing frustration and bottlenecks to growth. Should you build or buy your way out of the problem?

Read the entire article here.