Setting expectations

In the business world, a key part of communicating is expectation setting. Whether you are delivering a presentation or a set of requirements, not establishing expectations with your audience can lead to a few unfortunate outcomes.

1. Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
2. People may require you to perform additional work to produce something more acceptable to them. You'll get comments like, "I won't sign-off on this unless I see... such-and-such in there."
3. Your work is not perceived to be relevant. You'll be asked to go back and start over.

In marketing, there is a saying that, "If you do not position your product, someone will do it for you." Likewise, when communicating, "If you do not set expectations, they will be set for you." Think of what happens when you watch a presentation (or attend a meeting) with 10 other people. How many of them say things like,

• I didn't get anything from that.
• That wasn't what I expected.
• There were no details, I need details.

If you hear these sorts of statements, it indicates that people did not have a clear idea about what to expect and why there were there. In other words, the individuals responsible for delivering and setting up the presentation (or meeting) did not clearly articulate their intentions.

In one of my previous posts, I wrote about expectation setting as it related to the development of requirements. What resources you'll need access to, what tools you will be using, how you will be providing status updates and the facilities to provide feedback (and ultimately sign-off.) The last part of this is to explain and outline what will be in the actual deliverable.

Before I start writing about expectations for deliverables, recall that there are many different phases to a project's life cycle and for each one, different levels of information and different audiences are present. For each, a different expectation needs to be established.

Spotlight: business analyst

Allan Hoffman recently posted an article on Monster.com, Career spotlight: Business Analyst.

He lists the main factors for requiring more business analysts as:

1. The increase in outsourcing patterns.
2. A continuous drive for improved efficiency.
   

Mr. Hoffman points out that the most important thing a business analyst can bring to a project is translation; or a furthering of understanding about what is required.

Kathleen Barret, president of the International Institute of Business Analysis (IIBA), says business analysts' ability to translate -- an ability that's difficult to offshore -- is crucial to succeeding in the role. "[Business analysts] need to be there with the business," she says. "It's very difficult to do a good job virtually."

This echoes my thoughts from an early post, The why of business analysis. The central role of the business analyst is to foster understanding throughout the business and IT groups to provide the best basis for success.

Step back for a second, think about how easy it is to misunderstand and miscommunicate. Think about the costs and consequences associated to some of these misunderstandings when they happen on your projects.

Unfortunately, they aren't as humorous as the following video.

Requirements in an agile world

In my last post, I wrote about differences between projects that use a traditional project methodology versus ones that employ a more agile one. In the post, Choose a methodology that suits your project, I spoke of when you should use one methodology over another one. Is there an impact on requirements from different methodologies?

Recall the main characteristics of good requirements:

• Correctness
• Completeness
• Clarity
  
• Consistency
• Testability
• Traceability
• Modularity
• Feasibility
• Design Independence

These factors are essential to all requirements. However, when using different methodologies there are slight variances a business analyst should expect. The two pictures below show my thoughts on the key differences.All business analysts should be aware of these differences and the impact to their deliverables.

Agile Project Leadership Article

There's an interesting article on ProjectConnections.com called Agile Project Leadership. In it the author, Kent McDonald compares and contrasts traditional project management characteristics versus agile project management ones.

To summarize the article, the basic differences were:

• Task versus feature driven.
• Process and control versus anticipate and adapt.
• Fully detailed versus iterative project plan.
• Leadership versus team driven.
  

To this set of differences I would like to add something from one of my previous posts, System Development Life Cycles & Requirements,

• Process versus people-oriented.

If project management characteristics change depending on the nature of the approach taken, what about the approach to requirements? What differences would one expect to see? What concepts are important?