Archive of Communication Articles

A rose by any other name…

When we’re learning how to write in high school and college, we’re taught that synonyms make our writing more exciting. In fact, not using synonyms can make our prose clumsy and awkward.

When it comes to requirements, the last thing you want to do is use synonyms. Except sometimes.

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea - it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is what happened because of the investment.

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail - helping participants be prepared to participate - in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees - business analysts, product managers, and project managers, for example.

The material in the presentation is off-topic, but the presentation is so good that you just have to watch it. I found this when researching about openID (mine is http://tynerblain.com/scott.sehlhorst/ - check out myOpenID to set up yours). Consider the open ID thing to be a tangent you might be interested in pursuing today, and will be interested in pursuing soon.

Regardless, you should watch this presentation. The delivery will knock your socks off. The topic is interesting, or perhaps not interesting at all - but delivered so well that you’ll be interested.

This is your third link to it. Last chance.

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Active listening skills will help you guide your customers and your team to do the right thing, and enjoy the experience.

The first step of gathering requirements is to identify who can give you the requirements. Business processes include communication between different people inside the organization. Communication also includes people outside the organization. When gathering requirements, it can be easy to overlook the people who don’t use the software directly. Those people may still be stakeholders. Read on to see how to approach stakeholder analysis.

Effective communication of requirements requires more than documentation and broadcasting. Effective communication requires interaction and collaboration. Alistair Cockburn addresses this in his analysis of project successes and modes of communication.

We create project dashboards all the time to show status, or to give upper management an update. Dashboards and scorecards are great for giving us a “quick view” into the health of a project - they give us a way to drill down. Many of us use the colors red / yellow / green, with a stoplight metaphor. The problem is that some of us are colorblind. Johanna Rothman gives us a GREAT tip.