“Business Deliverables” ala ISDM 4.0 –

  • Project outline
  • The purpose of this document is to create a common understanding between the Project sponsor and Project manager and to create a historical record of the project.
  • The Project outline contains a brief description of the project intent, outcomes, deliverables and costs. Depending on the Project sponsor's requirements, risks and stakeholders may also be documented here.
  • Concept brief
  • prepared by Business, and expressed in Business terms
  • describe a proposal for a concept that could be developed into a project…enable the appropriate approval body to make a decision on whether or not to progress the concept to the next stage and level of detail
  • contains details such as purpose, intent, scope, drivers, benefits, costs, stakeholders etc. If there is an IT impact, may be accompanied by an IT produced Concept assessment.
  • Blueprint
  • they paint a picture of the user's experience
  • they thoroughly canvass the impacts of the project
  • they identify products, services and capabilities required to deliver the user experience, and
  • they provide indicative resource requirements.
  • Business case
  • justify the approval and funding of a project.
  • information on intent, scope, desired outcomes, deliverables and milestones, project management approach and schedule, risk and dependencies and includes a draft design Blueprint.
  • more detailed information on options considered and costs and benefits.
  • Statement of requirements
  • This document provides a business view of the required functional requirements and non functional requirements of a project.
  • The Statement of requirements should focus on the major IT products which have been identified in the intent and blueprint phase
  • The document is produced by Business as part of developing the Business case for the project to help with cost estimates in the IT scope plan for a project.
  • High level business design specification
  • This specification is produced after the "Statement of Requirements" and as part of producing the business case for the product.
  • This iteration focuses on identifying the high level business processes and manual and IT dependent process steps which comprise the processes.
  • Details of the business design are used as input to the high level application architecture which is used to help produce cost estimates in the IT Scope plan for a project.
  • Business process model
  • Business process model defines, enables, and manages the exchange of enterprise information through the semantics of a business process view, which involves employees, customers, partners, applications, and databases. It is a consolidated view of the tasks and responsibilities that the business undertakes to achieve its objectives.
  • data and flow … incorporate the mapping of responsibilities.
  • Business rules register
  • Business, not technology, oriented.
  • Business, not technology, owned.
  • Are derived from the business requirements.
  • Atomic: A rule is either completely true or completely false; there are no shades of gray. For example: a tax agent is only authorised to view the TFN/ABN of one of their clients.
  • Expressed in natural language: In order to appeal to the broadest audience, it is almost always best to express business rules in a natural language without the use of a lot of technical jargon.
  • Project close out
  • The purpose of this document is to record the formal termination of the project.
  • It includes information on implementation/handover arrangements and how uncompleted project work will be handled.
  • The Project close out should be aligned to the Project outline and the final Project status report.
  • Post implementation review
  • This document examines how well the application meets business needs (not necessarily the original requirements) and how the introduction into the business environment was handled. Its scope can cover the usability of the application, deployment and support. The main participants are business people.

What is in a Blueprint

Included / Content
 / Blueprint name and details
 / Document control
 / Table of contents
 / Executive overview
 / High Level Overview
 / Legislative arrangements
 / The intent of the initiative and drivers for the change
 / Users impacted by the change
 / The user experience (User pathways)
 / Co-Design Plan
 / High level design
 / Work processes
 / Products and services
 / Design risks, issues, dependencies and assumptions
 / Timeline
 / Measures of success
 / Appendix

Implementation planning has a strong management focus which requires best practice approaches, skills and experience to be applied in the following seven areas:

  1. Management Control and Program/Project Management
  2. Governance and Accountability
  3. Planning
  4. Resource Management
  5. Risk Management
  6. Stakeholder Engagement
  7. Review, Monitoring and Evaluation

Policy implementation is about creating a different future. An implementation plan must provide a clear picture of that future as it is the basis for the outcomes and delivered benefits of the new policy.

A clearly articulated vision and description of the desired future are vital to the buy-in, motivation and alignment of effort and expenditure of the large number of people involved in any new policy implementation. This element of implementation planning sets the framework for dealing with the “expectations” part of the objective “on time, on budget and to expectations”.

When departments and agencies need to deliver transformational change, different stakeholders will not necessarily understand the big picture without a vision statement. A good vision statement:

  • is written in the present tense as a description of the desired future state;
  • can be easily understood by a wide range of stakeholders;
  • is written with the broadest grouping of stakeholders as the target audience;
  • describes a compelling future that engages the heart as well as the head; and
  • is short/concise and memorable.

Vision statements must reflect:

a)the approved policy objective;

b)the policy context or environment, including the underlying need or problem, related policies currently in place and any previous policies, cross-jurisdictional or cross-portfolio issues, the legislative and regulatory environment, and key research and information that will influence the policy direction;

c)approvals to date including enabling legislation, relevant decisions by government and work already completed; and

d)the policy solution, delivery model or strategy for achieving the approved policy objective – this may be a brief statement of how the outputs will be delivered, how these outputs will achieve the desired outcome (policy objective) and how this outcome aligns with the Government’s strategic policy agenda, the agency’s Business Plan and outputs/outcomes framework.

To support the vision, which is only a summary impression, a more detailed picture of the desired future state is required. This much more detailed “blueprint” is primarily a design document, providing a meticulous description of the changed future state. It must incorporate all the key components that need to be changed or created as deliverables during implementation:

  • processes - changed legislation, department and agency processes, operations and functions
  • organisational structures – changes to departments and agencies and other bodies
  • technology and infrastructure – ICT, buildings, facilities and equipments

Couch benefits in SMARTA terms:

  • Specific
  • Measurable
  • Achievable
  • Relevant
  • Time framed
  • Agreed

Performance measures should adopt the right FABRIC:

  • Focused on your department’s/agency’s aims and objectives, relevant to what you are aiming to achieve and the scale and complexity of the particular measure or package of measures;
  • Appropriate and useful for those who will use these measures. Your performance measures should clearly link outcomes to your agency’s work (establishing intermediate outcomes if final outcomes are subject to too many factors that are not directly in your agency’s control);
  • Balanced in their reflection of priorities and total effort;
  • Robust - data should be clearly defined and collected consistently, measures should be easy to understand and use, data should be collected frequently enough to track progress, and quickly enough for the data to still be useful, measures should be reliable, comparable and verifiable;
  • Integrated in existing performance management processes; and
  • Cost-effective

Many departments and agencies have difficulty separating out the success factors for the implementation process as opposed to success in terms of a measure’s outcomes or impacts. It often happens that an implementation process is quite successful – everything happened on time and on budget – but the expectations of the government or the community weren’t met; in other words, ‘the operation was successful, but the patient died.’ The implementation plan needs to articulate a framework in which the success of the implementation process can be monitored, but is linked to an evaluation of the overall outcomes.

From the Cabinet Implementation Unit Guide to Preparing Implementation Plans, 2011

Core Design Team through Co-Design to Requirements for ICT

Inputs: a Blueprint document describing intent, with some ideas about how it might be achieved.

Outputs: Documents allowing an ICT project team to plan and conduct their work.

Note: while the ATO calls the output document “Business Requirements”, this is a misnomer, and the term should be reserved for a particular meaning in the industry.

Activities handled by the business project

  • The Communication Plan was managed by the BSL, and all stakeholder communications went through them.
  • Problem tracking with root cause analysis
  • Elicitation has already occurred, although the results are mainly in people’s heads.
  • Approved scope is usually different from agreed scope.

Business Requirements (BABoK use of the term)

Always conduct the following:

  • Develop several models of the requirements, based on the subject matter.
  • Stakeholder Analysis
  • Risk Analysis
  • Data dictionary and glossary

Options for modelling methods include:

  • Structured Walkthrough (A Day in the Life)
  • Process Models (At the Handoff Level) – may be summarised in a conceptual solution architecture model
  • Data flow diagrams (Data inputs, flow, and outputs)
  • Business Rule Analysis (trees and/or tables)
  • Screen flow diagrams
  • State diagrams
  • Scenarios and Stories

Conform to Standards

Link to Australian Government Architecture and ATO reference models, by identifying where this project or function fits. Categorisation happens within a hierarchical structure - Business Area, Line of Business, Subfunction, Business Services, Business processes

Identify where we use elements of the design continuum, including where we accept and use a standard model, and where we vary it.

Goal-driven

There is a related factor in how requirements are organised: to abstract thinkers, quite abstract categories to do with implementation may be acceptable. For concrete thinkers, we need to map requirements to the goals they meet.

[There is academic work on Goal-Orientated Requirements Engineering (GORE).] (here 'goal' means what we use the word 'benefit')

Early stage work by BSol may leverage constructs like GBRAM (Goal-Based Requirements Analysis Method) or KAOS (Knowledge Acquisition in autOmated

Specification) to identify goals and model their relationships. Of particular importance is knowing who gets the benefit from the goal, and how it compares to other goals, in case compromises are needed later.

Our documentation must provide traceability from the benefits, through the outcomes, through the goals, to the requirements. A benefits dependency network may be the graph used, or the strategic dependency model from i*. ICT will trace from our requirements through their effort (including development) and testing and support, typically with traceability matrixes provided by their ALM solution. Benefits-driven reporting requires both halves.

[Note that these relationships may be used in solution planning to calculate return on effort, if possibly cutting things back becomes necessary.]

For every benefit, how will it be measured? Are there existing KPIs to sue as a guide? What is ‘good enough’ to call it success?

Implementation of goals should be described using the Enterprise Business Motivation Model, which allows for describing influence and intent, as well as information flow and interrelationships.

A stakeholder map, identify concerns, should also be prepared.

(unlike this sample drawing, special attention should be paid to identifying shared concerns)

Situation Analysis

Compare the desired benefits/outcomes etc with what is currently available. What is the delta to make it happen? How does this fit with other activities?

Which corporate systems, capabilities, or data holdings are relevant?

What alternatives were considered, and why were they dismissed?

Solution Requirements

These principles are important for the business users to be able to understand the content and hence validate that we have the requirements correct. ICT will rewrite as much of this as they choose using more technical and more detailed language.

Decision Analysis (Choosing between options)

User centred, not system centic

Everything should be described in terms of the user experience and the artefacts the user might understand (like a form, an email, or a payment). Language should be from the user-world, and avoid technical terms as much as possible.

Concrete v Abstract

Different people have different abilities to deal with abstractions - some people just understand better when given more concrete examples.

Unlike requirements work at the technical level, where abstract thinking is more common, and people are used tothe requirements process, at our level we usually have new participants and at least some concrete thinkers.

Accordingly, to communicate effectively, we need different communication products - instead of a use case, a user story; instead of a workflow, a storyboard; instead of a UI spec, a mockup.

Business process mapping should be done at a very high level (typically the handoff level) and abstract out the difference between human and machine steps. It should use the simplest possible structures and shapes – flowchart or the descriptive conformance class of BPMN. (Later, in communication with technical teams, analytic BPMN may be useful, and the detailed developers may go down to executable BPMN.)

Data modelling should use representations of the form, screen, or report on which the data is captured, typically referring to the fields by their labels, not their technical names.

Perspectives of Analysis

Business Processes and Activities

Each activity needs to be assessed on a variety of grounds:

- volume of items to be processed, performance standards

- proportion that can be automated; of those remaining for manual, how hard?

Information analysis

- data dictionary and contructs meaningful to the actors

- data flow and CRUD analysis

- value of data and how to improve its worth

- custodian/steward

- reporting requirements

When is it ‘done’?

Be guided by the following principles:

  • This is the foundation for a detailed requirements phase which the ICT project will conduct: the goal is to set them up for success, not do their work for them. Accordingly scope is more important than detail.
  • “Perfect” requirements take too long, and the business need will usually have changed sufficiently to make them outdated. “Good enough” and “timely” are high praise.
  • In general, the author is poorly placed to assess any of the ‘qualities’ of good requirements: they are too close to the material. Try to get the most appropriate consumer of the products to make the assessment. For example:
  • The customer (the primary stakeholder) should be best placed to know if the requirements are right.
  • The consumer of the requirements (the person who will use the requirements document) is the best person to assess if the requirements are enough and/or usable.
  • A test manager is a good person to evaluate whether requirements are testable.

In the teams I have observed recently, that means more technical input to the draft requirements document. [Note also that a lot of the ‘words’ in the current BR document are of interest to the business project manager, not the technical teams, and could be compartmentalised. It’s a struggle to get ICT people to read, so we need to make the BR as short as possible.]

When what you want is the normal thing, it doesn’t need to be specified in detail – it is enough to say ‘logged in user’, or ‘print function’. Corollary: every time you specify something in detail, ICT will assume you want exactly what you asked for, not the ‘normal thing’. So only specify in detail when it is something you WANT included. While you might know that they will have to include other things, don’t specify those.

Justification

  • How have you ensured that each of the requirements is necessary? (Use the MoSCoW scale to make all necessary requirements as MUST, and other requirements as SHOUD, COULD, or WONT)
  • How have you checked that the requirements taken together will be sufficient? Generally you would need to determine whether the requirements documented against each goal were sufficient to achieve that goal.

How does this map against industry standards, like BABoK?

The Business Analysis Body of Knowledge (v2) describes 6 main process areas. Here they are illustrated by their inputs and outputs, with a side bar on how the function is currently performed.

Note that BABoK does not suggest that “business analysts” are the only people to perform these activities: it recognises that executives, consultants, project managers, developers – lots of different people carry out Business Analysis tasks. I think it would suggest that whoever does the task should be using a standard like BABoK to understand what is usually included in that task.

/ Subsumed in the original business case.
/ Subsumed in the original business case.
/ Conducted through Co-Design process, by skilled facilitators, although requirements management tends to be spotty, and elicitation results are not confirmed.
/ Not performed in BSol.
/ Core business for BSol
/ Core business for BSol

Looking at outputs, BABoK describes: