Blueworks Live is a great tool for documenting your business processes. But we often see inconsistency in the models that are produced. Some are highly detailed with plenty of information. Others just cover the bare minimum of information. In some cases, the models are only represented by a diagram. Of course, the true value of Blueworks live comes out when models have complete details - properties, problems, policies, detailed documentation and so on. 

In many cases I have seen incomplete models published into the business. Some organisations have a governance process that will catch incomplete models prior to publication. But this leads to rework. This post details a simple checklist approach that Blueworks Live Editors can use before they publish their Blueprints.

I have split the checklist into three sections:

1. Completeness - Is the information provided in the Blueprint sufficient to properly describe the Business Process?
2. Naming - Does the Blueprint follow a good, or approve, naming convention?
3. Correctness - Is the information in the Blueprint accurate?

Completeness - Checklist Items

• Space must have a description
• Space goals must be populated
• Process must have a description setting out its purpose and any critical features
• Processes are tagged with authorised tags (An official tag list should be published and maintained)
• Milestone documentation is populated
• The process diagram has appropriately labelled start and end events
• The documentation tab has been completed for each activity
• Properties fields have been completed
  (create a MOSCOW guideline for each property. E.g., “Business Owner” Must be completed, “Supplier” Could be completed)
• Activities that relate to business controls have been correctly identified and specified
• Decision details/rules are provided for all Decision task activities

Sample MOSCOW model for default Blueworks Live properties:

Naming

• Process must have an intuitive name (verb-noun)
• Activity names begin with a capital letter and follow naming conventions with a verb-noun structure
• Recommended activity verbs are used
  (Good: accept, add, calculate, communicate, delete, dispatch, generate, place, prepare, provide, receive, record, remit, request, send, submit, tabulate, update, validate, verify.)
  (Avoid: computer, database, display, email, fax, file, form, online, phone, print, process, report, transmit.)
• Correct use of Capitalisation 

Correctness

• Check all spelling
• All metadata is accurate and correct
• Milestones are defined in a logical sequence
• Milestones reflect the outcome of that stage in a process
  (A process milestone implies a previous milestone has been completed successfully (e.g., an order has been shipped). The important thing about the successful completion of a milestone is that all business rules applicable to its state must be satisfied.
• Happy path start and end events are in the same swimlane
• Intermediate events are labelled correctly and are of the appropriate type
• All swimlanes have activities associated with them
• Each Activity box uses the correct task type symbol: Normal/Default, User Task, Service Task, Decision Task, Robotic Task
• Any hyperlinks in documentation or metadata function correctly
• Policy links (where appropriate) are populated, and they work correctly
• Any attachment is relevant to the process and is the current/correct version
• Boundary events are properly used and defined
• Appropriate gateways are used and are labelled correctly
• All outbound flows from Exclusive and Inclusive Gateways are labelled with the activity outcomes
• Parallel paths initiated by Parallel or Inclusive Gateways required to have a "joining gateway" of the same type
• Choose the correct metadata from the BWL Glossary list (Add new items only if not already listed & required)
  (Ensure a governance mechanism is in place for Glossary values)
• Ensure the colour legend is populated to reflect colours used in the Process Diagram – use “official” colour legends if provided.

If Editors are encouraged to use a self-assessment checklist like the one detailed above rework should be greatly reduced, and consistent and effective process models can be made available to the business.