Monthly Archives: August 2006

Outside Reading: Product Manager vs. Product Marketing Manager

Marketing, Product Management

reading outside

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

I typically view that Product Marketing Managers are ‘outbound’ and are responsible aligning the product with the market/customer. The could/should deliver the requirements to the Product Manager who will build the requirements into the development or engineering cycle.

Jeremiah Owyang

A good discussion thread has started on the post too, including a link to pragmatic marketing’s survey results on breakdown of responsibilities. Jump on over to Jeremiah’s post and join in the discussion (or post here, of course). From the survey results, it seems that both product managers (PM) and product marketing managers (PMM) commonly have product strategy responsibilities as their primary focus. Technical product management falls to the PM, while marketing and sales support fall to the PMM.

This data supports the perspective that PMM is more outbound while PM is more inbound.

Jeremiah makes a good point that with startups and small companies, specialization is an expensive luxury. In a technology or software startup, the founders often set product strategy – at least initially. I think that making the distinction between PM and PMM in a small company is pretty irrelevant. Regardless of title, both sets of responsibilities will fall on the same person. As the company grows, the opportunity for specialization becomes realistic.

Perhaps the best argument for dividing responsibilities based on an inbound/outbound focus is to support future recruiting. While there is a lot of variation in the industry – that does seem to be the most common differentiator. And it is certainly the easiest to explain to recruiters (as a candidate or as a company).

More of this meme:

Approval Process Pain Management

Business Process Modeling, Requirements, Requirements gathering

comedy and tragedy

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.

Two dimensions

There are two dimensions that we can control when getting approval for the requirements in a given project. The first dimension is controlling how much we want to approve in a single session. The second is controlling how many people are involved in each approval session. Think of these two dimensions as quantity and democracy.

Quantity

Many projects will create a monolithic requirements document, for example, an SRS that represents the specification for an entire solution. This document will / may / should be subdivided into different areas. We might break down an SRS into the sets of requirements that support different goals. We might organize requirements based upon the affected areas of our customer’s business. We might organize them by release.

Many projects will also involve business process modeling, and we can either lump all of the modeled processes together, organize them into groups of related (or interdependent) processes, or treat each process individually.

We can control the quantity of requirements/processes/documentation we approve in any given session.

Democracy

There can be several stakeholders for a given project or even a given requirement or process. There are usually many people who are involved in a process, or who would benefit from improving it. And those people can be represented by someone with authority (a manager, a project sponsor, a company visionary). Enterprise software often involves and benefits people from multiple organizations – each of whom may appoint a representative for the purpose of getting approvals.

There are also stakeholders on the implementation side of a software solution – development, testing, and training organizations come to mind. Again, each group will have multiple involved people, and may elect a single representative.

We can control the democracy of an approval session by controlling how many people are invited to any given session.

The Levers

The more content we try and review in a single session, the more painful that session can be. Each evaluation should involve critical thinking and concentration. We gather business owners to validate correctness of a requirement (or process document). We gather implementation team members to validate completeness of a requirement.

Limit an approval session to the amount of documentation that can be reviewed in one to two hours. Less than an hour makes it difficult to “create” the context required to make insightful decisions about correctness. More than two hours will glaze the eyes of participants, and gaps and errors are more likely to slip through.

Shorter sessions lead to less pain.

As we increase the number of people invited to an approval session, we risk crossing the event horizon of the design by committee singularity. Eventually so many agendas are collected in one conference room that no good ideas can escape. Time itself is slowed by the density of the participants.

When possible, identify a single business owner with authority and responsibility for each grouping of requirements / processes that need to be evaluated. Many organizations will make this impossible, as they are still experimenting with the matrix and cross-functional reporting structures. Limit a session to three authorities when a clear owner can not be identified. Have multiple sessions if you must.

Fewer people per session leads to less pain.

Dogfooding

We are currently supporting the first phase of a multi-year project, documenting as-is business processes. We have organized our processes into about a dozen functional areas, segmented by business objective. We have a few dozen processes that we have identified as being affected in the current phase of the current project.

Today I facilitated identification of a single business owner who approves each individual process. And we agreed to approve each process individually. That’s a lot of meetings and approvals, but we have about half a dozen business owners and as many business analysts, so it will be manageable. The main risk to this approach is that we overlook the “touch points” between processes. We will also work to validate the big picture, so that we properly validate our representation of the connections between the processes. We may review multiple processes per meeting, but we will strictly adhere to our timeboxing of two hours per session.

We are also only doing business signoffs after the following are true for each process:

  • Subject matter experts and the authoring business analysis agree that the documentation is correct.
  • Peer review by other BAs on the team has reviewed for style, quality and consistency of documentation.
  • The technical / implementation lead for the project has reviewed the documentation for “implementability” by checking for ambiguity, verifiability, attainability, and sufficient level of detail.

Conclusion

When going through the approval process for validating requirements and process documentation, we want to minimize the pain and maximize the benefits of approval sessions. Manage meetings to last between one and two hours, with no more than three approvers (one if possible). Adding time or people reduces the quality of the feedback.

Building the Case for Requirements Management Tools

Consulting, Presentation, Requirements management software

Movie Projector

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.

The Final Product

Marcus made his presentation available to us via his esnip account (v 1.2 is the one I reviewed). Even if you aren’t interested in the genesis of the presentation, you should get it and read it. And if you don’t care about pitching for requirements management tools, you want to get the presentation anyway – it is a fantastic real-world example of many of the Beyond Bullets and Presentation Zen techniques.

Marcus’ effective use of imagery is the reason we have images with our articles. So effective on his site that we couldn’t pass them up here. I’ve been learning from him ever since – and in the presentation – even more and better use. Images supplant text, instead of just augmenting it.

The Approach

Marcus does it exactly right – he develops an understanding of his audience, including their goals, needs, and backgrounds. Then he designs a presentation to show how their goals are addressed, in a language that is consistent with their backgrounds – he adapts to the context of the listener. Awesome. Then he iterates and builds out the presentation.

Targeting his communication for his audience makes more of a difference than anything. Funny how few people do it.

The Genesys

Check out Marcus’ work and progress via his articles:

Conclusion

Marcus creates better presentations than we do. Maybe next time we can get him to videotape it – he probably delivers them better too. Thanks for sharing this stuff with us!

BPMN Diagrams – Never Too Late For An Intermediate Timer Event

Business Process Modeling, Requirements, Requirements gathering

bpmn diagram

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.
Background

We presented an introduction to BPMN diagrams over a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.

Intermediate Timer Events

The BPMN intermediate timer event allows us to either have a process wait explicitly, or have a process react to the passing of time. In this article, we will look at an example of a business process that branches off in a different direction when a deadline has passed.

In this business process modeling example, a contractor performs work for a client, submits an invoice, and then receives payment for the work. If the invoice is not received within 30 days of the invoice due date, the contractor contacts the client with a follow-up call, and then receives the payment. If the payment is still not received within 90 days of the due-date, the contractor writes off the bill as a bad debt.

bpmn boundary intermediate timer event example

The default behavior, as represented by the sequence flow, is that the contractor receives payment after submitting an invoice. If 30 days pass after the due date of the invoice, it represents an exception to the desired business process. The exception handling routine is easy to differentiate from the normal flow of the business process.

Here’s what the equivalent process would look like in a classical flow chart. The classic flow chart represents the exception handling of a delayed payment with a decision box that loops back to the original “receive payment” step in the process. The same “loop back” technique could have been used in the BPMN diagram, but the format chosen above is easier to read and more explicit in indicating the normal process from the exception process.
classical flow chart delay modeling example

Summary

We can model exception processes with intermediate boundary events. An intermediate timer event, when placed on the boundary of an event, represents what happens after a specific delay, or at a specific time (if the process is still within the annotated activity when the timer is triggered. This can be modeled with classical flowcharting techniques, but they are more cumbersome, and also are less effective at presenting the difference between the intended process and the built-in exception handling.

BPMN Diagrams – Wait For An Intermediate Timer Event

Business Process Modeling, Requirements, Requirements gathering

bpmn diagram

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.

Background

We presented an introduction to BPMN diagrams over a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Intermediate events are one of the more unfamiliar items in the BPMN language. They also allow for some of the cleanest, unambiguous expressions of steps in business processes.

Intermediate Timer Events

The BPMN intermediate timer event allows us to either have a process wait explicitly, or have a process react to the passing of time (for example, if someone does not pay a traffic ticket within 30 days, a citation will be issued). In this article, we will look at an example of a business process that waits until a predetermined time before continuing.

When we use an intermediate timer event within the sequence flow (aka normal flow) of a process, it indicates that the process will wait. An intermediate timer can be defined to wait for a fixed amount of time – 30 days, 20 seconds, etc. An intermediate timer event can also represent a delay until a fixed time or date. For example, a continuous integration process might wait until 3 a.m. before initiating network-intensive automated tests.

In this example, a process waits until either the first or the fifteenth of the month before continuing.

bpmn diagram example of intermediate timer event

This is a business process modeling example of the compensation relationship between a contractor and an employer. The contractor does work, submits an invoice, and receives payment. The employer receives an invoice, and then waits until either the first day or the fifteenth day of the month before paying the contractor.

The BPMN representation of this delay is very easy to model and to read with an intermediate timer event. We can imagine the business queueing up all contractor payments until the 15th of the month. We can imagine a desperate business waiting even longer when trying to manage cash flow problems, or earn extra interest at the expense of their suppliers.

If we were to use a classical flowchart to depict this delay, the employer’s process might look like the following

Classical flowchart example of a delay

While this can also be easily understood, it requires an extra step of processing to evaluate the common decision-point symbol with its flows to determine that it is acting as a delay. With larger diagrams, this can become somewhat tedious. The BPMN intermediate timer event, is starkly contrasted by the intuitive interpretation (clock equals delay) and distinctive appearance without additional flow elements (connectors).

Summary

The intermediate timer event, can be used to represent delays in a process by including it in the sequence flow of the process. It is distinctive in appearance and easy to read. The proper interpretation of an intermediate timer event is straightforward, unlike a decision element in a classical flow-chart, which is overloaded to achieve the same functionality.

Alphabet Soup – Requirements Documents

Requirements, Software development

alphabet soup

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.

Background

There is a spectrum of specification for software projects, ranging from “vision” to “algorithm”, and all points in between.

We’ve described the software development process with an onion metaphor. Given that framework of ever-increasing-specificity, we’ve also looked at the flow of moving from market requirements to design, and proposed particular combinations of documents. The flow generally looks like the following:

Requirements flow

Michael’s Analysis

Michael looks in more detail at the “requirements” and “spec” levels in the above diagram and provides some perspective about how different companies approach and label documentation. One challenge – different companies use the same names to mean different things.

Check out Michael’s post – more good stuff from him (we subscribe and recommend his blog for everyone interested in product management)!

Making Agile Offshore Teams Work

Agile, Process Improvement, Software development

western gymnasteastern dancer

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.

Agile and Offshore

To be agile means more than just having an incremental delivery process. Agility is built on communication – ideally face to face communication. Technology has all but eliminated the communication barriers of geographically distributed teams. But technology can’t solve the problem of temporal displacement that comes with teams operating in different time zones.

Communication starts with requirements and moves through development and testing. In an incremental delivery process, this is a continuous, cyclical process with small elements of functionality being processed in each cycle. Offshore teams – and most outsourced teams, regardless of location, prefer a more contract-based relationship. These supplier-consumer type relationships are traditionally managed through delivery against a specification. Martin calls this a plan-driven process in his article.

To be offshore and agile, we have to avoid the extremes and follow the best of both approaches. We have to recognize a couple immutable truths about the operating theater of splitting a team across the planet:

  • Communication is not real-time. While there is some overlap, we must account for asynchronous communication between team members.
  • Cultural barriers are just that – barriers. We can surmount them, but only after first acknowledging them.

Martin’s Guidance

Martin provides a fantastic (and long) article about how his company has made it work. Here are some of the key points from Martin’s article, along with our commentary.

  • Use Continuous Integration. Martin points out how effective this is (for any team) at preventing the integration problems that come up in any large or complex software project. Those integration problems, when not prevented, are solved through collaboration and communication. Since the teams are seperated temporally as well as geographically, these interchanges become very inefficient. The key is to prevent the problems, in order to avoid the inefficiencies of solving them without colocated collaborators.
  • Cross-Pollinate the Teams. Don’t just send some people over to the “secondary” location to get things started. Rotate key contributors through month+ stays at the remote site to establish an ongoing rapport and relationship. Martin also suggests having recurring visits from other team members both to initiate and cultivate relationships. It is these relationships that build the foundation for informal and effective communication.
  • Organize by Feature, not Function. Avoid the traditional offshoring approach of doing analysis onshore, construction offshore, and then testing onshore. This “waterfall model” serves to create political barriers between the teams, as hand-offs and responsibilities lend themselves to finger-pointing when things go wrong. Martin suggests that we try and distribute work so that each team can own as much of the process as possible for each given feature. Splitting the work this way improves the efficiency of communication within each cycle.

There is a lot more in Martin’s article. Check it out!

BPMN Diagrams – Boundary Intermediate Message Events

Business Process Modeling, Requirements, Requirements gathering

bpmn diagram

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 intermediate message behavior we previously described, which show how to use intermediate message events in the course of the normal sequence flow of a business process.

Background

We presented an introduction to BPMN diagrams over a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

On The Edge (Exception Flow)

When an intermediate event is placed on the boundary (or edge) of an activity, it is a representation of how a business process responds to an exception – a deviation from the normal sequence flow of the process. Some intermediate events (including intermediate message events) can be used on the boundary of an activity.

When an intermediate message event appears on the boundary of an activity, it indicates that an incoming message can interrupt the activity, and will divert the sequence flow from the “normal” flow to an “exception” flow. The intermediate message event can be placed on the boundary of a task or of a sub-process. If placed on the boundary of a subprocess, it can be attached either to the collapsed or the expanded subprocess boundary.

BPMN diagram example of intermediate message event on a task boundary

In the business process modeling example above a hungry dog (for example, a Labrador retriever like Scout, whenever concious) will faithfully pursue an agenda of eating anything he can. The dog will watch the owner leave the kitchen, put his paws on the counter, and if he can get away with it, procede to eat any available people food. Once he’s done eating, he will resume his normal activity.

If, however, Scout is interrupted with a loud “No” message, he will display a guilty* appearance for a brief period before resuming his normal activities.

guilty scout

When an intermediate message event is placed on the boundary of an activity, like the looping “Eat People Food” task, it represents a possible exception flow. If the associated message (“No”) is received, the activity is interrupted and the alternative (exception) flow is followed.

Summary

An intermediate message event can be used within the normal sequence flow of a business process. It can also be used to designate specific behavior for the interruption of an activity upon receipt of a message. This interruption is handled via exception flow which may or may not reconnect with other tasks in the sequence flow.

*He may just look at you funny or completely ignore you. YMMV.

Yesterday’s BPMN Post Was A Big Fat Lie

Administrivia, Business Process Modeling, Requirements, Requirements gathering

Joker

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 been demonstrated.

This “bonus post” is primarily for the benefit of our email subscribers, who would not otherwise know that the post had been updated.  People who subscribe via RSS would receive an updated version of the post, and the excerpt has also been updated, so that people visiting the main page of Tyner Blain will know that the post has been corrected.
Sorry for the confusion.

Scott

BPMN Diagrams – Flowing Intermediate Message Events

Business Process Modeling, Requirements, Requirements gathering

bpmn diagram

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 to correct a glaring error on Aug 22nd, 2006]
Background

We presented an introduction to BPMN diagrams almost a month ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

Flowing Freely

Business process modeling is about a lot more than showing a sequence of steps and decisions – it is also about showing communication. Communication can be achieved with message flow objects from an activity in one pool to an activity in another pool. Or a message can come from or be received by a message intermediate event within the sequence flow of a process.

In the following BPMN example, a message start event initiates a process, which will wait until it receives another message before being completed.

BPMN diagram of message intermediate events receiving

The broker (who’s internal process is not defined, using what is called a “black box swim pool”, sends a message which is received by the investor, initiating the purchase of ACME stock. The investor’s process then waits until another message is received from the broker, suggesting sale of the stock. The investor then sells the stock and the end of the process is reached.

The two key takeaways are that the message intermediate event is a “step” – the equivalent of “Receive Broker Suggestion”, and that the Investor’s process waits until it receives notification from the broker in the form of a message. After the message has been received, the Investor’s process can continue, but it is hanging in limbo until then.

This BPMN example shows an intermediate message event that is an element of the sequence flow. If the message is never received, the flow will never finish.

[Update: Previously, there was a section explaining how intermediate message events can be used to send messages, with an example showing how message flow is originated from the intermediate message event. However, this is not supported, per section 8.4.2 of the 1.0 version of the spec.

  • The original diagram has been replaced with one that is marked up to show the error.
  • The original text associated with that diagram has been replaced with text explaining the error.
  • A new diagram depicting the proper way to model the same business process has been added.]

[Start Changes 23 Aug 2006]
BPMN intermediate message events can be used to send messages, but they can not be the source of message flow because no intermediate events can be the source of message flow. What this means is that an intermediate message event can not send a message to a participant in a different pool. All message flow travels from one pool to another.
example of incorrect bpmn diagram of intermediate message event

To demonstrate messages being sent from the broker to the investor (for the process diagrammed incorrectly above), we would use the following diagram.

example of corrected bpmn process

In the corrected diagram example, we see the broker’s process as well as the investor’s process. After ACME generates a “Buy” signal, the broker calls the client and suggests that she buy shares of ACME. After ACME generates a “Sell” signal, the broker notifies the investor to sell her ACME stock.

An intermediate message event within normal flow can be used to send a message, according to table 9.8 in section 9.3.4 of the spec. The spec does not explicitly explain the apparent contradiction of this statement with the prohibition against message flow originating from an intermediate event. Our interpretation is that an intermediate message event, when sending a message, must be sending it to another participant within the same pool (who is not eligible to receive message flow).

The following example shows how this might happen.

bpmn example of intermediate message event sending message

The broker, after the “ACME Generates ‘Buy’ Signal” task, uses an intermediate message event to send a message to other brokers (within the same swim pool) notifying them of the buy event. The process has also been updated to show an alternate start to the process – a message start event can trigger the flow when the notification message is received.

Message flow is shown to the investor, but only from the task “Suggest Purchase…”

Summary

Intermediate message events can be used either to “halt” a process while it waits for a message, or they can be defined when messages are sent from within a business process. When intermediate message events are used to send messages, they can only send them to other participants within the same swim pool, because they can not be the source of message flow (even if they are the source of messages).

[End Changes 23 Aug 2006]