Monthly Archives: July 2006

BPMN Diagrams – Introduction To Activities

BPMN Diagram

An introduction to the Activities elements of business process modeling diagrams.

Background

We presented an introduction to BPMN diagrams two weeks 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).

Activities

Activities are initially very straightforward – they represent the things that happen within a business process.

A fun and simple example comes from the Underpants Gnomes made famous in episode 217 of Southpark. In short, the gnomes form a corporation that has a single, simple business process with three phases:

  1. Steal Underpants.
  2. ????
  3. Profits!

A very funny commentary on many dot-com business models. A BPMN diagram of the gnomes’ corporate plan looks like the following:
Underpants Gnomes BPMN Diagram
Each box with a rounded rectangle represents an activity. The activities flow as drawn with the solid arrows from each rectangle to the next. Notice that the activity for “Phase 2” is different than the other two activities – there is a small box with a plus sign (+) in the center of the bottom of the rectangle. The other two activities do not have a plus sign.

There are two main types of activities – tasks and sub-processes. When the activity has a plus sign, it is a sub-process. When it doesn’t, it is a task.

BPMN Task

bpmn task example

BPMN tasks are easy to read – what you see is what you get. There is one task, represented by one rectangle. This is the simplest form of activity used in business process modeling.

BPMN Sub-process

bpmn sub-process example

BPMN sub-processes are a very handy way to roll-up, or combine a whole process into a single activity. This is a great way to make high level process diagrams easy to read. The plus sign inside the rectangle indicates that it can be “expanded” – that there is another process inside of it. For the software folks out there, this is a simple form of encapsulation. For the non-software folks, a sub-process is a level of abstraction that allows us to talk about an entire process as if it were a single step.
We could create diagrams without subprocesses. To be useful, business process modeling has to go down to a pretty detailed level of representation. Any relatively complex or large process will quickly become unreadable if every detailed step were displayed.By analogy, think about the wiring diagram for a computer motherboard. We can see a bunch of boxes (chips) connected to each other. Someone who knows how to interpret the traces on the motherboard could understand this. Inside each chip are millions or billions of additional boxes and steps, encapsulated like the sub-process activity. If we had to look at all of those circuits whenever we looked at a motherboard, we would be overwhelmed with complexity. When we don’t need to look at the details, we show the sub-process. When we do need the details, the sub-process will be defined separately.

The gnomes in the Southpark cartoon are funny because they have no idea what the sub-process is. They are just merrily working against the high level plan that we showed in the example. The problem for the gnomes is that they never created the sub-process. Reminds us of the “advertise website during the superbowl, ????, profits!” model.

Summary

Business process modeling allows us to draw easy to read diagrams that show the steps in a business process. Each step is an activity, and there is a flow from one activity to another. Some activities are tasks that represent a single action, while other activities are sub-processes that represent an entire contained process.

There are more details and ways to diagram tasks and sub-processes. We will discuss them soon.

Agile Argument

Agility

Another challenge to a premise of agile comes in a well assembled argument from Tony at Seilevel, in his article, Agile…again.

Perspective

At Tyner Blain, we believe in the power of requirements. We sell services in product management, business analysis, and other elements of the software process. Everything we do strives for Software Product Success. Tony has a similar disclosure:

Some people have pointed out that the reason I don’t like agile methods is because I am trying to sell services which depend on “traditional” requirements. The reason I like “traditional” requirements is because I don’t like screwed up projects.

We firmly believe that there is benefit to defining the goals of a project (requirements) before beginning the project. While we are occasionally guilty of using hyperbole when contrasting different software approaches, we stand behind the spirit of those arguments.

Processes that trivialize requirements definition activities are flawed processes. Processes that over-emphasize requirements gathering (e.g. “Big Up Front Requirements”) are also flawed. An underemphasis introduces the risk of missing critical requirements. It also increases the likelihood that the team will sub-optimize by focusing their initial efforts on the wrong requirements. An overemphasis on “defining everything” before we begin to deliver valuable solutions can cause problems too. By delaying delivery, we magnify the impact of requirements gathering errors.

The question, ultimately, is a matter of degree.

Opposing Perspectives

People who push for minimizing pre-development requirements efforts often justify that approach as a response to projects that wasted a lot of time on the wrong requirements. As Tony points out, the fundamental requirements or goals (market requirements) do not change frequently. Imagine a product manager identifies requirement “A” as the most important one. After delivering the software, the customer is dissatisfied with “A” and the product manager is faced with a decision. Should he accept blame for doing a bad job at gathering requirements, or should he claim that the requirements changed after he specified “A”? I think too many people fail to accept responsibility, and blame it on “change”.

How many times have people tried to create a mass-market pen-based portable pc? Did the requirements change, or did the teams just pursue the wrong objectives? What about Microsoft’s Bob operating system?
For people that push for heavy up-front requirements work, it is a command and control issue. Personally, I’ve seen a lot of high-caliber implementation teams thrash around “searching” for great products, and delivering (well-implemented) junk. Maybe that’s why I believe in the value of having a vision and a set of goals.

Feedback

Feedback loops are great. In the engineering world, a process without feedback is considered to be out of control. Incremental delivery is the mechanism by which we put feedback into the software development process. There are small feedback loops throughout the process, but the big one is customer feedback. These feedback loops make incremental delivery a good idea.
Feedback is a key component of agile software development. Feedback only works when you respond to it – hence the adaptation to changes in requirements. If the initial requirements are bad, the project can only succeed if the feedback requirements are good enough to replace the initial bad requirements. If the initial requirements are good, then the feedback requirements are requirements of refinement not replacement.

I, and I suspect Tony, believe that the best way to run a project is with good initial requirements and with feedback requirements that help us refine our vision or approach or design and implementation. This dependence on feedback does not preclude the need for good initial requirements. And that availability of feedback requirements does not obviate the need for good initial requirements.

Conclusion

Tony is right, and the passage he quotes from Agile modeling is unfortunately misguided. Good initial requirements are not impossible to gather. Failing to do so is expensive and dangerous. Incremental approaches that allow for customer feedback throughout the development process are outstanding. The ideal way to apply the feedback is in the refinement of initial requirements, not the replacement thereof.

BPMN Diagrams – How To Use Gateways

BPMN Diagram

Business process modeling examples showing how to use the five different gateways defined in the BPMN specification.

Background

We presented an introduction to BPMN diagrams last week. 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).

Gateways

Gateways are the evolution of the diamond-shaped boxes we’re accustomed to in flow charts. In BPMN, gateways can have one of five distinct interpretations. The gateways are used in diagrams both to separate flows and to recombine them.

  • Exclusive OR (XOR) Decision/Merge based on data
  • Exclusive OR (XOR) Decision/Merge based on an event
  • Inclusive OR (OR) Decisions/Merge
  • Complex Decision/Merge
  • Parallel Fork/Join

BPMN Gateway Legend

Exclusive OR (XOR)

An exclusive OR, which logicians call XOR, represents a decision to take exactly one path in the flow. More than one path can not be taken – they are mutually exclusive, hence the name. This is the behavior generally assigned to the familiar diamond from flow charting.

Data based XOR Gateway

The first thing to note is that this gateway can be drawn in either of two ways. It can be drawn as an empty diamond, or as a diamond with an ‘X’ in it. Whatever style is chosen, it should be consistent within the diagram and all diagrams. We prefer to use the diamond with the ‘X’ in it.

BPMN diagram example of data based XOR

In our business process modeling example above, after opening the mail, the person will either read the mail (and then discard it), or discard it without reading it. The first gateway represents the choice based on data available in the process. The available data is the content of the mail (either junk or real).

The second gateway is optional. We also could have drawn the diagram as follows:

Alt BPMN Diagram Example of data based XOR

Event Based XOR Gateway

When an event, such as an external message, causes us to make an exclusive OR (XOR) decision, we use a different XOR gateway. The distinction is if the information required to make the decision is available within the process (use data based) or comes from an external source (use event based). This will make more sense when we consider the example business process model.

BPMN Diagram example of event based xor

In this business process modeling example, our actor invites a girl to the prom. If her response, a message that is external to the process, is yes, the actor rents a tuxedo and attends the prom. If she says no, he will stay home and play XBOX games all night.

We could also have modeled this by bringing the girl’s response into the process as data. Once it is in the process, we would use a data based XOR gateway, as shown in the following example.

Another BPMN Diagram example of a data based xor

This alternative approach, while potentially easier to read, is also more verbose (Adding an extra task to the process). Either style is acceptable in the BPMN official spec. We suggest using the event based gateway for a cleaner diagram.

Inclusive OR Gateway

An inclusive OR Gateway specifies that one or more of the available paths will be taken. They could all be taken, or only one of them.

BPMN Diagram example of inclusive or gateway

In this example of a business process model, our actor purchases a car. After that purchase, if the car needs to be cleaned, it will be cleaned. Also, if it needs to be repaired, it will be repaired. If the car needs to be both cleaned and repaired, both things happen. The possibility that neither a cleaning nor repairs are required.

The first OR gateway represents the control of the flow of the process along one or more paths in the model. The second OR gateway represents the reconnection of those paths and the continuation of flow. When reconnecting paths like this, the OR gateway explicitly requires that all paths that were activated must be completed prior to continuing in the process.

By explanation, if the car needed only to be cleaned, then the car may be driven once the cleaning is done. If the car needed to be both cleaned and repaired, the car could not be driven until both the cleaning and repairs were completed.

Complex Decision Gateway

A complex decision gateway allows for a more expressive decision within a business process. Multiple factors, rules and analyses can all combine to yield results. The analysis should result in at least one path always being taken.

BPMN Diagram example of a complex decision gateway

In this business process modeling example, our student takes the SAT (a college entrance/aptitude exam common in the USA). If the student scores under an 800 (the possible scores range from 200 to 1600), the student will enroll in an expensive class to improve his test score – and then retake the exam. If the student performs moderately, he will read a low-cost book designed to help him improve his score – and then retake the exam. If the student scores above 1000, he will immediately attend university.

Parallel Gateway

A parallel gateway (also called a fork, or join) is used when a process can perform multiple branches of operation in parallel.

BPMN Diagram example of a parallel gateway

In this business process modeling example, our inventor invents a better mousetrap. The process flow then splits (forks) into two parallel paths. Along one path, the inventor files for a patent. In the other branch, the inventor creates a prototype. Once both of those steps have been completed, the inventor gets rich.

A fork gateway (the first one) explicitly states that all paths must be followed. A join gateway (the second one) explicitly requires that all paths have been completed before advancing the process. Our inventor can not get rich without a patent, and also can not get rich without a prototype.

Summary

We now know how to use the five different types of gateways in our business process modeling diagrams. We should use the BPMN diagramming standard to make our diagrams consistent within and across projects.

BPMN Diagrams – How To Use Start Events

BPMN Diagram

Examples showing how and when to use the 6 different types of start events in business process modeling notation (BPMN) diagrams.

Background

We presented an introduction to BPMN diagrams last week. 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).

Start Events

Each business process has some form of initiating event. In BPMN terminology, it is called a start event. There are six different types of start events that we can include in a BPMN model.

  • None – the modeler does not specify the start event.
  • Message – a message triggers the start of the process.
  • Timer – a time, a date, or a recurring time or date triggers the start of the process.
  • Rule – evaluation of a rule initiates the process.
  • Link – this represents the start of a sub-process that is part of a larger process.
  • Multiple – more than one form of trigger can initiate the process.

Start Event Legend

None

When we aren’t certain of, or do not want to specify the start of a process, we can use the empty circle, or none start event. We also use this start event when the trigger for the process is irrelevant.

Example of the 'none' start event

In this BPMN diagram example, the process shows that we first get our eggs, then scramble them and eat them for breakfast. We don’t indicate why the process was started. It could be because we were hungry, because we’re on a dietary schedule, or because our mom told us we had to eat our breakfast. We don’t know, or care. Trying to figure out what triggers the egg scrambling process doesn’t help us understand the process any better – so we use the none start event.

Message

When a process is initiated by an outside actor sending us a message (telling us to start the event), we use the message start event.

Example BPMN diagram of the message start event

This BPMN diagram example shows a process of getting water, giving it to a child, and returning to bed. The process is initiated by the receipt of a message. We become aware that the child is complaining of thirst and unable to sleep. When we receive that message, we initiate the process of getting water for the child.

Timer

The timer event is used in BPMN diagrams to indicate that the process begins at a set time or date. It can also be used for processes that repeat on a schedule (hourly, daily, etc).

BPMN diagram example of the timer start event
In our example, on the actor’s wedding anniversary, he buys a gift, gives it to his spouse, and then enjoys their anniversary. This process is triggered by the timing of the anniversary.

Rule

A business process that is initiated according to the evaluation of a rule or condition is initiated with a rule start event. A rule can have any amount of complexity or simplicity.

BPMN diagram example of rule start event

In this BPMN diagram example, the rule might be “If caller ID indicates a friend or family member.” When the rule evaluates to true, the process is started. In this process we answer the phone, talk, and then hang up the phone. But we only do this if the call is from a friend or family member.

Link

A link start event is a special case. It indicates that we are looking at a sub-process, or part of a larger process. In the larger process, the flow will enter into a sub-process activity, at which point the flow transitions to our detailed process diagram. The sub-process starts at the link start event and continues to the end event. When the detailed process reaches the end event, the flow returns to the larger, or parent process.

BPMN diagram example with link start event and sub-process

In this BPMN diagram example, we start with a modified version of our egg-scrambling process. Note that the “Scramble Eggs” activity has been changed from a task to a sub-process. The diagram on the right shows the sub-process.

The entire flow reads as follows:

  • [parent process] Unknown start event
  • [parent process] Get Eggs
  • [parent process] Initiate Scramble Eggs sub-process
  • [sub-process] Link start event
  • [sub-process] Stir Eggs
  • [sub-process] Apply Heat
  • [sub-process] Stir Eggs
  • [sub-process] If not done, return to Stir Eggs
  • [sub-process] end event – returns flow control to parent process
  • [parent process] Eat breakfast
  • [parent process] end event

Multiple

A business process may be initiated by any of multiple different events. When we don’t know or care what those events are, we can use the none start event. When the process initiator is important, we use the multiple start event. Additional notes or documentation will indicate the possible starting events.

BPMN Diagram example of multiple start event

Our television watching process (turn on tv, watch tv, turn off tv) could be initiated because we want to be entertained, or because we want to be educated. This might matter because it could impact what channel we watch. We might be turning it on at a precise time, every morning, to check for school closings. We might just want the tv for background noise while we do something else. Since we care about how the process is initiated, we use the multiple start event instead of the none start event.

Summary

We now know which of the 6 BPMN start events to use in any BPMN diagram. We should use the BPMN diagramming standard to make our diagrams consistent within and across projects.

Quick Thoughts on Incremental Project Management

ruler

Incremental delivery planning is not an oxymoron.  You just plan the soon-to-happen tasks in detail, and keep the distant tasks more vague.  Does this make sense?

Rolling-Wave Planning

Johanna Rothman has posted an article that provides a good introduction to rolling-wave planning.  She explains that she manages incremental projects with biweekly deliveries, and manages the project schedule four-weeks out.  Each week, she updates the plan.  At the beginning of the project, she outlines the milestones (which are subject to change in incremental projects).  She only goes into details on the tasks that will happen in the next four weeks.

Johanna describes two reasons for picking four weeks.  First, less time provides less visibility into project risks.  And more time leads to more errors (and more changes to the plan).  She suggests managing tasks at the 1 to 2 day task-size.

Quick Thoughts

Johanna’s ideas are good ones.  We should always have a detailed plan for the current delivery cycle, as well as the next delivery cycle.  This allows us to manage requirements changes and the impact of changes.

If we are using a monthly iteration cycle, that means two-months of detailed planning.

When we complete one cycle, while the development team starts to work on the (now) current plan, the project manager is working to build out the plan for the next release.  This begins (for the project manager) by meeting with the product manager to identify any changes in prioritization, scope, or content.

As the (now) previous release was coming to a close, the product manager should be meeting with stakeholders to manage expectations about what is included in this release.  This communication should be a reminder only.  The product manager will also let the stakeholders know what is being developed in the (now) current release.

When the release is delivered to the stakeholders, the product manager will get the feedback needed to adjust priorization or make requirements changes.  Those changes will make it into a future release.  If they are critical, they could potentially be worked into the “next” release – although that may cause some process pain for the project manager.

So, at any given point in time, we have the following roles and activities:

  • Stakeholders review previous release (release n-1) and provide feedback to product manager.
  • Stakeholders are informed of content for the current (release n) and the next release (release n+1).
  • Development team works on defined plan for the current release (release n).
  • Project manager is defining or managing the plan for the next release (release n+1).
  • Product manager is updating priorities and managing requirements changes for the release after that (release n+2).
  • When urgent changes are required, the product and project managers will coordinate to make changes to the next release (release n+1).

The Impact of Change and Use Cases

green puzzle piece

Market requirements change. These changes impact the use cases that support the changing requirements. Functional requirements change. These changes impact the use cases that they support. How can we leverage use cases to manage these changes? And how can we manage changes to use cases?

Background

We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.

Structured Requirements

When we use a structured requirements process, use cases support market requirements or goals. The use cases themselves are then enabled by functional requirements, and sometimes non-functional requirements.

structured requirements structure

Collectively, the functional requirements and non-functional requirements make up the software requirements specification, or SRS.

Different people view requirements from different perspectives. Something as simple as intent can mean completely different things to stakeholders and implementers. Depending on your role on the team, why, what, and how can mean very different things. The following diagram shows the perspectives of team members (stakeholders and product managers share a similar perspective).

perspectives on the software development process

Requirements Documents – One Man’s Trash

Changing the Software

Change happens. And changes flow downhill. As the first diagram shows, when we make a change anywhere in the process, it will cause changes in each of the “lower” areas. Each change also has to be validated back up the chain, to make sure that the implicit contracts between areas of the diagram are maintained.

Note: we’re using language that presumes changes have been approved, to make this article easier to read. Keep in the back of your mind that there may be outstanding approval processes that are not covered in this article. We did this instead of saying “approved changes” or “proposed changes” every time we could just say “changes.”

Changing Market Requirements

The goals of a software project can and should change over time. One of the benefits of incremental delivery is that we can identify changes to the needs of the business before we deliver the software. This allows us to adapt, which gives us a greater likelihood of achieving software product success.

Before a goal has changed, we will have defined the use cases that enable the goal. And we will have confirmed that the use cases are both correct and complete for achieving that goal.

After a market requirement has been changed, we need to revalidate that it is both correct and complete. We do this by reviewing the supporting use cases. When we identify which use cases support each market requirement, we can narrow the scope of our review to only those use cases that support the changing requirement.

Those use cases might need to change, or they might be obsoleted by the change. We may need to add one or more use cases to meet the new requirement. But with a form of traceability from the market requirement to its supporting use cases, we can focus our efforts on only the relevant changes.

Changing Use Cases

A use case can change because one or more of the market requirements it supports has changed. A use case may also be independently changed, because someone has proposed a better business process for achieving the same goal. A business analyst or interaction designer may be responsible for these changes.
When a use case has been changed, we must first verify the completeness of the market requirements it supports. Does the change in the use case cause us to no longer achieve our objectives?

We then have to validate the correctness of the use case. Is this changed use case correct?

Once a use case has been changed, the non-functional and functional requirements that are derived from the use case must also be evaluated. The notion of traceability from use cases to their supporting requirements allows us to narrow the scope of our analysis. The same logic described in the previous section applies here too.

Changing (Non)Functional Requirements

Functional and non-functional requirements can change because the use cases they enable have been changed. Functional requirements may also be changed because a software designer has proposed an alternative approach. This software designer could be an interaction designer or a senior member of the implementation team. The point to remember is that there is ideation involved in writing the requirements that support a use case.

If design wasn’t required, then writing an SRS would be both self-evident and programmatic, given a particular use case. And if that were true, then CASE tools would have found a very large market and flourished. Simply put, they haven’t.

As in the previous sections, when requirements in an SRS are changed, the upstream relationship must be reconfirmed – do they continue to support their respective use cases?

Downstream impacts of a change to the requirements spec are addressed in the scoping of the implementation team. Each change in requirements can result in changes to the design or implementation. Those changes must be evaluated for their impact on project costs and schedules.

Traceability helps us to narrow the scope of our analysis here too. Only those directly supporting requirements need to be evaluated.

Summary

Change happens. When it does, it propogates “down” the structured requirements diagram. We use traces between the artifacts to minimize the effort of evaluating those changes. We also use traceability to confirm that the previous characteristics of completeness and correctness still hold true.

Business Analyst BOK 1.6 Just Released

releasing a balloon

The IIBA (International Institute of Business Analysis) has just released version 1.6 of A Guide to the Business Analysis Body of Knowledge, or the BA BOK. This new release adds over 100 pages of content and is the first “essentially complete” version.

The IIBA was founded in 2003 with an exciting charter:

The IIBA is the independent non-profit professional association serving the growing field of Business Analysis. Whatever your role — requirements management, systems analysis, business analysis, requirements analysis, project management, or consulting, if you are involved in analysis for systems, business or process improvement, IIBA can help you do your job better.

The BA BOK

The business analysis (BA) body of knowledge (bok) is a massive 329 page pdf ebook available at the IIBA home page (pdf direct), that strives to include “everything” needed for the very broad role of business analysts.

The Business Analysis Body of Knowledge is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. As with other professions, the body of knowledge is defined and enhanced by the business
analysis professionals who apply it. The BOK describes Business Analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution.

BA BOK 1.6 http://www.theiiba.org

Joining

The IIBA costs $95 per year in annual membership dues. There is an online forum for the IIBA.

End

Since we just pointed you to 329 pages to read over the weekend, we won’t write any more in this article. Have a great weekend!

Iron Triangle Kills in Boston…

boston skyline

… Skyline Unharmed

Short-sighted demands on software teams usually don’t kill people. Software development is often described with a construction analogy. The Big Dig construction project was under exactly that kind of pressure. On July 10th, 12 tons of tunnel ceiling collapsed and killed a motorist. On July 20th, Mitt Romney ordered the tunnel to be closed. Let the finger pointing begin.

Background

The Big Dig is a multi-year construction project to fix very expensive traffic problems in downtown Boston. The Massachusetts Turnpike Authority has a good background article. Traffic congestion was projected to cost $500 million per year to motorists by 2010 without making changes. Project costs – $14.6 billion (more than 30 year payback period) versus an initial estimate of $2.5 billion.

overpass

The 6-lane overpass was to be replaced with 8 to 10 lanes of tunnels underneath the city, protecting the skyline of Boston from large concrete structures. Unlike the “protect the view” argument of previous New Orleans adminstrators against a hurricane barrier, there are practical arguments to building tunnels. The MTA was never proposing to “do nothing.”

Project Timeline

According to this Associated Press article, the Turnpike Commission found no problems that “rose to the level of a public safety threat.”

Timothy Johnson, author, project manager, and owner of Delta Project Solutions, speculates in his article that the source of poor quality may have been pressure on the engineering/construction teams to work faster.

It doesn’t take a lot of effort to find stories of the governor’s office pressuring the project to move faster. There was political capital on the line. So… the project moved faster. Quality shortcuts were inevitably taken. And now Mitt Romney wants to know where the blame lies. Am I missing something on the cause-and-effect graph?

Corrobarating Evidence

The US Transportation Department released a scathing audit this week, charging Big Dig officials with misleading federal officials on Feb. 1 that the project would cost $10.8 billion, and divulging later the same day that it could cost an additional $1.4 billion.

“It stands as one of the most flagrant breaches of the integrity of the federal-state partnership in the history of the nearly 85-year-old federal-aid highway program,” the audit said.

Gov. Paul Cellucci (R) fired the head of the Big Dig, James Kerasiotes, just minutes after meeting with federal highway officials. But that does not solve the larger issue of how to complete projects of this magnitude on schedule and on budget.

Christian Science Monitor, April 2000

From the same article:

The Big Dig, he points out, is the worst example of cost overrun [Ernest Frankel, a professor emeritus at MIT’s school of engineering]’s ever seen. He and his colleagues warned Massachusetts officials that the project could not be done for the state’s initial estimate of $2.5 billion. Which raises a larger point: While government officials often claim – rightly – that added time and costs are necessary on big projects, critics say authorities too often low-ball construction schedules and estimates to gain funding and public support.

Why Quality Suffers

When project constraints put the squeeze on, there are four ways we can respond. The common expression of the Iron Triangle is that a project can be represented as a triangle with three legs – cost, time, scope. If you put pressure on the project without increasing one of the legs of the triangle, then quality suffers. In this project, it looks like the consequences of pressure were mortal.

  1. Sacrifice quality to increase functionality
  2. Increase cost to increase functionality
  3. Increase time to increase functionality
  4. Delay some functionality to deliver other functionality

How To Use Timeboxes For Scheduling Software Delivery

Apparently, the folks on the big dig were pressured to choose option #1, which is not a good idea. They also apparently made liberal use of options 2, 3, and 4. Perhaps there were competence problems, or process problems, but regardless, politics trumps people the same way that people trump process.

Conclusion

Don’t sacrifice quality to meet some arbitrary metrics. Without accounting for sunk costs, review the project from its current state to its projected end state. If the additional time and costs will still allow the project to meet the ROI targets, then keep working. If not, cancel the project. If you go with option 1, bad things can happen.

Communicating A Release Schedule With Use Cases

purple puzzle piece

We manage release schedules with project management. We manage customer expectations with consulting skills. How do we manage customer expectations about release schedules? With Use Cases.

Background

We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.

Scheduling

There are many books written about how to manage software development, and about project management in general. The Art of Project Management, by Scott Berkun, is an excellent one. In addition to those great works, we’ve written a few articles of our own:

  1. How To Use Timeboxes For Scheduling Software Delivery
  2. Scheduling Requirements Changes (part 1)
  3. Scheduling Requirements Changes (part 2)
  4. Managing Scope Creep is Not a Zero-Sum Game
  5. Communicating a Delivery Schedule With Use Cases

The Main Idea

The first three posts give us primers on how to manage our team’s capacity, and how to use some rigor when accepting inevitable change requests without jeopardizing our projects. The fourth article shows how we can turn scope-creep into an opportunity.

In the fifth article, we presented our initial thoughts on how to use use cases to communicate delivery schedules.

Setting expectations with users and other stakeholders requires that we communicate the schedule of delivery for our software. Stakeholders don’t think or care directly about when feature X is enabled. Feature X is implicitly worthless. When a user can perform a particular use case, which depends upon feature X – that’s what they care about. The executive who funded the project cares about when the business will see a financial benefit from using the software, which is achieved through a set of use cases, which in turn depend upon feature X.

That article goes into more detail, proposing a grid layout for showing when particular user personas will perform a particular use case.

Conclusion

Critics might argue that we’re recycling old content for this post, but we feel its important enough to say twice. Besides, how many of you were reading Tyner Blain in Dec 2005? Leave a comment if you were – we would love to hear from anyone who was reading way back then. [hint: our avg daily subscriptions are up about 5000% since then.]

Foundation Series: Business Process Modeling

classroom

Business Process Modeling

Business Process Modeling (BPM) allows us to increase our understanding of business processes and improve communication with stakeholders and implementation teams. Business analysts will create diagrams that represent business processes. These diagrams can be used to elicit requirements, define scope, and improve communication within the team.

We use diagrams because they are intuitive. Diagrams can provide us with an easy to remember and understand visualization of a business process. These diagrams are a type of object oriented analysis (OOA) diagram. A BPM describes a business process, where an entity-relationship (ER) diagram describes business objects. The example in the previous link is an ER diagram.

A Simple Process Model

The easiest way to get a high level understanding of a business process model is to review the diagram for a simple process.
The following diagram represents a customer withdrawing money from their bank account. The customer convinces the bank that she is allowed to withdraw money, then requests the money, which the bank provides (after confirming that it is available). The customer then terminates the transaction.

The diagram does not show exceptions to the process, like having the wrong password, or not having enough funds in their account. Business process models can absolutely demonstrate these situations, and many others. We’ve kept this process simple, as it is an introduction to the concept.

The BPM Example Diagram

atm withdrawal diagram

Swim Lanes and Pools

The first thing you will notice about the diagram is that all the activities happen in one of two areas, labeled customer and bank. These two areas are called pools. While that seems like a silly name, there is a reason for it. There is a type of diagram called swim lanes, designed to show how different people or entities interact. Each person gets a swim lane in which all of her actions happen. In BPM, all of the swim lanes for a single company are grouped together in a pool. In our example, each pool has a single lane.

In our diagram, there are two pools – one for the customer, and one for the bank.

Flow Objects

Our diagram includes examples of three flow objects: events, activities, and gateways. Events are represented as circles. We have starting events (triggers) at the top of the diagram and ending events at the bottom. Activities are drawn as rounded rectangles. An activity can be a single task (like “confirm logout”), or they can represent an entire sub-process. Our simple example shows only tasks.

Gateways represent points in the process where the flow can separate or combine. The diamond is the symbol used to represent a gateway – and it is common to see it in a flow chart, showing how a decision can cause a process to go in one of two directions. The two examples in our diagram show flows combining, with a “+” symbol inside the diamond. This implies that both inputs are required for the process to continue. For example, the steps “Deliver Cash” and “Update Account Balance” must both be completed before the sytem can “Receive [the] Logout Command”.

Sequence Flow

The solid arrows that connect all of the items within each pool are called sequence flows. They represent the flow of the process from one flow object to the next. Notice that there are no sequence flows from one pool to another. These solid arrows can cross swim-lane boundaries within a single pool, but never across pool boundaries. Since our example has a single swim lane in each pool, we don’t see this.

Message Flow

The dashed arrows that cross the pool boundaries are called message flows. A message flow represents communication between two entities. In our example, the customer sends a message to the bank asking for $100. The bank sends a message to the customer in the form of $100.

A Lot More

There are a lot more details to BPM. We’ve left them out to keep the introduction simple (and “brief”).

BPMN Standard

There is a standard notation to use in business process modeling, called BPMN. Business Process Modeling Notation is the industry standard for drawing diagrams. By using the same notation, every diagram becomes easier to read. All of the official documents can be found at www.bpmn.org.

This site has tutorials, the official standard (BPMN 1.0 [Feb 2006]), and other documents. There is even a visio stencil ([removed dead links] [Update:  Thanks Andy!] The links to the visio templates you have are dead but I found the updates. Updated links as of 17-July-2012 are: Visio 5Visio 2002Visio 2003) that can be used to draw diagrams consistently with a minimum of fuss.

– – –

Check out the index of the Foundation Series posts which will be updated whenever new posts are added.