Jeremiah Owyang, a Silicon Valley Community Manager writes about the difference between product managers and product marketing managers.

Gathering requirements is a fun job. But once they are gathered and documented, we have to get them approved before anyone can use them. Approval is important. We can do it the easy way or we can do it the hard way.

Marcus Ting-A-Kee has assembled a great presentation on the value to his company of requirements management tools. In addition to creating the presentation and sharing it with all of us, he shares the process of creating the presentation in several articles.

Business process modeling in the real world requires us to represent how processes deal with exceptions, delays and deadlines. Intermediate timer events can be used to model deadlines and the business processes for handling them. See an example of how to model a business process where two deadlines expire and the business responds.

Business process modeling requires us to model behaviors of people and organizations. Those behaviors often involve waiting. Prescribed delays, or waiting for a specific time or date is what we can represent with an intermediate timer event in the sequence flow of a BPMN diagram. This article shows an example of how to model this delay in a business process.

This is my requirements document. There are many like it, but this one is mine. My requirements document is my life. [Kubrick, with some editing]. Michael provides a comparison of requirements documentation formats seen in the wild. A good companion to our earlier piece, Michael provides some “what to expect” guidance about how different companies use the different documentation formats. Check it out.

Agile processes stress communication and colocation. Splitting a team into on and offshore resources inhibits the first and prevents the second. Teams struggle to resolve this apparent conflict of interest. Applying best practices (for any team) to address these challenges makes it possible. Martin Fowler provides us with great guidance based on years of experience with his company.

Intermediate message events can be placed on an activity boundary in BPMN. This use represents a form of exception handling for a task or sub-process, in response to an incoming message. This is a very different behavior than the ones we previously described, which show how to use intermediate message events in the course of the normal sequence flow of a business process.

Yesterday’s post contained a pretty significant mistake (aka “Big Fat Lie”).  I showed a diagram that was in violation of the BPMN specification for intermediate message events.
The post has been corrected, showing both the “bad” instructions, and the associated corrections.  The proper way to use intermediate message events within the normal sequence flow has also [...]

One of the 9 intermediate events in BPMN is the message intermediate event. There are two ways to use the message intermediate event, as an element in the sequence flow, or as an attachment to the boundary of an activity for exception processing. See how to use message intermediate events in a sequence flow. [Updated with correction of glaring error on Aug 22nd, 2006]