An effective status report is one that
- Instantly conveys the state of the project.
- Creates a minimum of overhead for the project team.
- Gets you help when you need it, and latitude when you don’t.
- Is fun / energizing to the author and the readers.
An effective status report is not a myth, it is actually easy to achieve.
Continue reading Effective Status Reports
Having trouble working through complex concepts? Struggling to get a “simple” message across? As human beings, we are all pre-wired to absorb visual communication. You should take advantage of that to give yourself an edge when it comes to communicating.
Continue reading Get an Edge With Visual Communication
The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!
Continue reading Defining Problems With Cause And Effect Diagrams
When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.
Continue reading Making Offshore Design Work
Economic pressures are driving most companies in high-developer-salary markets to explore using offshore development teams as part of their approach to developing software. Developing software with a global team presents new challenges as well as new benefits. If you do it right, you can have a more cost-effective team. If you do it wrong, you can have a disaster.
Continue reading Making Offshore Development Work
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.
Continue reading Requirements Writing Style and Synonyms
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.
Continue reading Why Separate Rules from Requirements
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.
Continue reading Measuring the ROI of Design
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.
Continue reading Failure To Deliver Is Not An Option
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.
Continue reading Planning for Effective Meetings