Business Process Modelling And Project Methodology

Project Methodologies and Business Modelling

This document discusses how to go about establishing modelling standards and guidelines. In general, a project rarely simply adopts a detailed style guideline from another project or another organisationat least not without evaluating it. So the very first step in deploying style guidelines is to make sure that your project is using a set of guidelines that is suited to its needs. We look at the issue from three points of view:

Setting modelling guidelines that analysts can refer to while they are producing models, 2. Setting guidelines that reviewers can use when they are evaluating models during an approval or delivery stage in the project 3. And making sure that the project can deal with the inevitable need for change and refinement in guidelines
1.

The following sections look at each of these points of view in more detail.

Creating Modelling Guidelines

The importance of modelling guidelines depends on the importance and complexity of the modelling. For example, if process models are being used only as an internal tool to help business analysts move quickly from ignorance to understanding, then detailed guidelines may not be critical. On the other hand, when models serve as a key tool for mapping business requirements or system requirements, good guidelines may be serve to save costly miscommunication or delay. The guidelines that modellers use should not really be defined separately from the guidelines that reviewers use. The definition of what is the standard or good practice is the same for both. But there is some difference in the emphasis. In this section we look at guidelines for making models. The modelling guidelines for a project must be clearly and concisely documented, and they must be practical. That is, they should relate to the practical work functions the business analysts are responsible for. If they do, then from the analysts point of view the guidelines are a manual. Analysts will deliberately use the guidelines because they make them more effective at their tasks. The are several typical work functions to consider:
1. 2. 3. 4.

Producing Models Storing and Sharing Models Security Publishing

5. 6.

Tracing Requirements Day to day administrative tasks

The following sections look at each area in more detail.

Producing Models
One of the key issues to address is how to allocate modelling responsibility between individuals in a team of analysts. Any project will proceed from the start with some system of dividing up the modelling work. For example, analysts may each be assigned responsibility for modelling business processes within a given business unit or subject matter domain. However, teams of modellers within a given modelling project always have to find ways to share some entities, concepts, or models. If the team is using a business process modelling software tool, then there will be issues regarding how to physically share data objects. If not, there are still new identifiers, concepts, or terms that must be used in common. Experienced analysts will recognise that communication of knowledge and information between team members is a key factor influencing how quickly a project can progress. The pratical aim of modelling guidelines should be to assist good communication as well as avoiding error.

Roles
We recommend that projects must clearly define the roles of modellers, including the distinct responsibilities for each type of modellers. A key aspect of this role definition is defining ownership for distinct sets of models and entities such as processes, activities, requirements. The user accounts that are created for software modelling tools should be logically related to the roles of the users. The modelling guidelines may be the appropriate place to document user accounts, groups, permissions, and how these relate to the modelling tasks.

Communication
Projects and teams need to develop good processes and habits of communication, although this is not necessarily controlled by guidelines. Policies about how often teams meet, and what kinds of modelling issues require email notification might be mentioned in guidelines. Communications with key stakeholders or external stakeholders is more formal and may be covered in modelling guidelines because models may form an important part of stakeholder communications.

Storing and Sharing Models

The processes for saving and accessing model data must be well-designed and documented. We recommend including information about these processes in modelling guidelines. The guidelines should provide a manual to help analysts get up to speed with using the process and serve as a reference.

Repositories and Formats

Even when using software modelling tools, the maintenance of data integrity and usability are as much the responsibility of the users as a function of the system. We recommend documenting the technical details about on-line model files and the repositories they are kept in, specifying any requirements that exist about the way the models are saved or formatted, and any configuration of the repository that may be relevant to modellers.

Sharing Data
Even when using software modelling tools, the ability of a team to share access while avoid conflicting changes depends as much on the discipline of the users as the functions of the system. We recommend documenting the steps that team members follow for all common data access steps.

Security
We recommend that guidelines should describe the security objectives of the project in practical terms as well as specifying rules that analysts must follow. As much as possible correct setting of permissions on assets should be an automatic consequence of following storing and sharing processes.

Publishing
Publishing models from an on-line repository is often requires detailed or complex steps. This is particularly true if there are numerous publishing formats or non-default formats required. We recommend that publishing steps for modellers be thoroughly documented. Responsibility for publishing should be delegated to a special publishing role as much as possible.

The Format of the Modelling Guidelines

To be easy to use and refer to for modellers, guidelines should be concise, reasonable thorough, and written in plain English. They will consist of different kinds of content:
1.

Prescriptive Rules
It should be clear that some of the rules are requirements of the project, and these requirements should be written so that a modeller can quickly assess whether they have been met.

2.

Non-prescriptive Rules
The guidelines should include rules that are only helpful hints. These should cover the most problematic common issues that modellers face. Aspects of quality that are subjective or difficult to evaluate should be treated as non-prescriptive for practical reasons.

3.

Examples and How-Tos

In order to facilitate learning, and to provide quick help for modellers, guidelines should be described as step-by-step instructions whenever possible. This is the best format for documenting administrative tasks, or the use of the software tools.

We recommend that the standards and recommendations that modellers are meant to follow be documented as a checklist of prescriptive rules, plus a manual of non-prescriptive rules. This same checklist should also serve as the basis for evaluation during the peer review process.

Creating Evaluation Guidelines

The deliverables of a business analysis or business modelling project should always be subjected to a few review processes. These reviews process must be defined before the project gets underway. Because models and other documents are the main output of a business analyst team, a project charter for a business process related project usually must focus on the quality of the documents themselves as one of the only ways to validate and approve the completion of the analysis phase. Clearly the business analyst team itself will want to review the quality of their output before the approval stage, in order to make sure it is ready for a project owner audience to assess, and as a means of reaching the building the highest quality business possible within the constraints of the project. A process of peer review is one of the effective approaches possible for such a validation or quality checking step.

Projects very often take an incremental approach, and reviews of various scope may be scheduled at any point in a project. As we noted above, the guidelines used for evaluation are based on a base of standards and recommendations that would also be built into the modelling guidelines. We recommend that the standards and recommendations that modellers are meant to follow be documented as a checklist of prescriptive rules, plus a manual of non-prescriptive rules. This same checklist should also serve as the basis for evaluation during the peer review process.

The Review Process

We recommend that modelling teams use peer review at intervals in a project, to evaluate the quality of the final deliverable. We recommend that a modelling team give consideration to the stakeholder review process, and the internal peer review process at the beginning of the project.

Roles
A good modeller should also be a good reviewer. A business modeller will naturally be most interested in feedback from a skilled and knowledgeable business analyst. We recommend that reviewing skills and responsibilities be developed and required for roles that involve modelling skills and responsibilities.

Communication
We recommend that the process for scheduling peer reviews and providing feedback be documented.

Reporting
The requirements for delivering models for approval or finalisation, such as format of reports, should be established or discovered ahead of time so that the processes and responsibility for preparing reports can be properly considered and documented as part of the evaluation guidelines.

Standards Review Process

The process of establishing modelling guidelines may be quite time consuming. No matter how much time a team spends on the guidelines however, it may be impossible to get them 100% perfect before the project starts. Instead, teams should aim to agree on standards rather than achieve perfection. They then should look for ways to be flexible and adapt the standard later. We recommend that a modelling team consider having a standards review process. To do this the team initially agrees on a standard, paying special attention to making the standard flexible or open to change if possible. The review should take place after the team has had some experience using the initial guidelines on real deliverables. Parts of the guidelines that provide non-prescriptive rules instructions for administrative tasks may be easy to change at several stages in the project without compromising the project. It may be more difficult to modify standards that effect notation, formatting of repositories, etc. There are several reasons why a team would go through the disruption of modifying their standards. Issues surrounding the modelling standards would have to be causing greater costs or worse risks than the cost or risk of changing. The review process itself should be built around assessing these likely issues:

Acceptability or compatibility of publishing format Time required to publish Requirements tracing (can models be mapped to project requirements) Inaccuracy or error (are there too many errors in the models) Legacy import (do the new models need to integrate with legacy models) Tool support and skill set (does the team have the skills to use or administer the needed tools) 7. Security requirements 8. Data modelling (can system implementers extract the necessary data model from the business models) 9. Knowledge capture (are modellers creating ad hoc documentation because model doesnt accommodate all the concepts they want to capture)
1. 2. 3. 4. 5. 6.