From start to end

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.

Your material is perceived to be unsuitable. It may be too detailed or contain too few details.
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."
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:

The increase in outsourcing patterns.
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:

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?

VIDEO: Excessive Jargon

Here's a short video that parodies what happens when you use too much jargon. No one understands anything!

Disaster Recovery, Requirements Management & Alignment resources

Here are some resources I've come across that may help you.

Requirements management
Best Practices for Enhancing Project Success is a recorded webinar that you can watch at your leisure.

More than 70 percent of software project failures can be traced to poor requirements management. The root cause: the gap between what the business team wants, and what is communicated to IT for delivery back to the business.

Disaster Recovery
CIOs lack confidence in their DR plans

IT execs are insecure about their disaster recovery plans.

That's according to a new survey by Rochester, N.Y.-based Harris Interactive Inc. that reported 39% of executives polled gave their plans a letter grade of C or worse, revealing a troubling lack of confidence in disaster readiness.

The survey results also indicated that this lack of confidence in disaster recovery planning is growing. A similar survey conducted in 2004 found that only 24% of executives gave their plans poor grades.

ALL-IN-ONE GUIDES: Disaster Recovery

This All-in-One Guide will get you on the path to a good, solid DR plan and show you what you need to do to maintain it. It starts you off with DR planning and design with understanding recovery capabilities and tools, and then takes you right through to DR implementation, security and testing.

Alignment
IT/Business Alignment

The IT/business alignment topics page provides CIOs and IT management with up-to-date information and resources on budgeting, IT governance, IT spending, leadership and strategy, and Return On Investment / Total Cost of Ownership.

Power Within

On September 13, I had the opportunity to attend a Power Within speaking engagement being held in Toronto. The event looked very promising with speakers such as Micheal Eisner, Sir Richard Branson and Tim Sanders taking part. You can see the full details about the session here.

Micheal Eisner's speech on management was very interesting. He spoke about how Disney used inside-the-box thinking to spur creativity and innovation for their entertainment initiatives. This may sound contrary to the outside-the-box paradigm that is prevalent now, but what Mr. Eisner meant was that for a given project you must understand the size of the box (e.g., amount of resources and money you will devote to it) and innovate, manage and be creative within those confines. He used clips from movies such as Who Framed Roger Rabbit, The Lion King, Outrageous Fortune and Pirates of the Caribbean - Dead Man's Chest to illustrate his points. The complexity concerning things one would not give much thought to was astounding. The example shown was the shading on Roger Rabbit's character while a overhead light swung back and forth (the picture is courtesy of Disney via Google.) This was something that was extremely challenging to perform at that time.
Tim Sanders was a former motivational coach at Yahoo! Mr. Sanders was an engaging speaker and talked about what he termed the, "likability factor." The basic premise is that people who are more likable are more prone to succeed versus an equally competent but less likable individual. He reasoning (backed up by lots of research) was as follows:

People want to work with individuals they like.
People will be more willing to assist someone they like. Such as give them information that will provide an advantage in a negotiation or a business deal.
When choosing between two identical proposals, the one from the individual you like more will generally win.

Mr. Sanders pyramid of likability was as follows (I've stated it upside down):

Friendliness - Make people feel welcome and comfortable.
Relevance - Validate commonalities between yourself and others.
Empathy - Understand feelings are facts. Be a good listener. Don't judge or try to fix the problems.
Realness - (At the top of the pyramid) be genuine. When someone is talking to you, give them your complete attention.

The keynote of the event was Sir Richard Branson. I must admit that this part of the event was a little of a letdown. It was run as an interview session with questions from the audience. Mr. Branson has significant charisma, however I did feel he rambled and didn't necessarily answer questions the audience's questions.

The event itself was good on a whole. If you can find a session keynoted by someone like Bill Clinton, I'd definitely say to check it out!

Webinar: Harnessing Emerging Technologies

Here's an interesting webinar, How to Harness Emerging Technologies to Boost the Bottom Line, from Ziff Davis.

Why do innovative companies find benefits from emerging technologies that others overlook? How do their IT teams use new technologies to create products and services and add value for customers? How do they help drive business innovation and keep competitors at bay?

View it on-demand here.

1, 2, 3 align your projects!

What are the steps involved in aligning projects to a strategy?

There are many different projects that a company can undertake. The first step is to create a list and make sure that everyone understands what each project is about.
Determine the criteria you will use. Your criteria should match your strategy and be representative of the direction you want your company to follow. For example, if you want to be a low cost provider, one of your potential criteria could be, "that a project should reduce the costs of service or increase the efficiency of providing service using your call centre."
Some things are more important than others. Weight your criteria.
Let the project sponsors individually score the importance of the projects using your criteria. Tabulate the results to reduce bias that the sponsors may have towards a one project or another. Projects that score high align more closely with your company's strategy and direction.
Establish high-med-low groups of projects.
The groupings and individual rankings form a basis for prioritizing.

By the end of this process you will have determined objectively which projects align better with your overall strategy and goals. Note that there are factors other than strategic fit that determine which projects will ultimately be undertaken (e.g., compliance, ROI.)

Webinar: Getting Agile with Your Projects

There's an upcoming webinar that maybe of interest.

Wednesday, September 27, 2006, 2:00 pm Eastern, 11:00 am PacificTap into the power of Agile software development with Dr. Alistair Cockburn, one of the forefathers of the Agile movement, and learn important risk-reducing strategies for your projects. Developing executable code that offers business value is the heart of project delivery, and using tools that support the collaboration and distillation of business rules and requirements into automated test suites is imperative. Fergal McGovern, originator of Optimal Trace, the leading Requirements Definition and Management Tool, will outline how a structured approach accelerates successful project delivery.

Enroll here!