Business Process Modelling and Project Methodology

7/30/2019 Business Process Modelling and Project Methodology

1/7

Business Process Modelling

And Project Methodology


2/7

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:

1. 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 changeand refinement in guidelines

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

Creat ing Mo del l ing Guidel ines

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 costlymiscommunication 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. Producing Models

2. Storing and Sharing Models

3. Security

4. Publishing


3/7

5. Tracing Requirements

6. Day to day administrative tasks

The following sections look at each area in more detail.

Producing Mod els

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

Communicat ion

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.


4/7

Stor ing and Shar ing Mod els

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 andserve as a reference.

Reposi tor ies 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.

Securi ty

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.

Publ ishing

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.


5/7

The Form at of the Model l ing Guidel ines

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 RulesIt 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 RulesThe 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 bedescribed 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.

Creat ing Evaluat ion Guidel inesThe 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 ameans 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.


6/7

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 Proc ess

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.

Communicat ion

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

documented.

Report ing

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


7/7

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:

1. Acceptability or compatibility of publishing format

2. Time required to publish

3. Requirements tracing (can models be mapped to project requirements)

4. Inaccuracy or error (are there too many errors in the models)

5. Legacy import (do the new models need to integrate with legacy models)

6. 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)

Documents

Business Process Modelling and Project Methodology