Constructive quality assurance - Information Management

Transformation: Corporate Development and IT
Part 5
Quality Management in Large Scale Projects
Thomas Gutzwiller
31.12.2006

How do we define project quality?
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
2

Determinants of project quality – the magic triangle
Project costs
Project time
Benefit of design products
(scope of benefits)
It is normal, that projects cause quality problems,
that means that costs, time or benefits are not
fully reachable.
This must be managed accordingly.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
3

What is quality assurance?
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
4

Basic connections – Categories of quality assurance
• Constructive quality assurance
Constructive quality assurance means, that project process is clearly defined, in
terms of
– A specific project process
– A general project management method for an overall steering of the projects
• Analytical quality assurance
– Analytical quality assurance means review and testing of design products and auditing of the
project processes
Process quality determines product quality
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
5

Basic connections – Categories of quality assurance
Quality assurance
Constructive
Analytical
Project
process
model
General
project
management
process
Review
Test
Audit
Quality
control
Quality
test
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
6

First diagnosis in a bad going project
• When the project team must develop the project process itself or when there are
differences about the right procedure...
• When there are “Stars” in a project, who manage the project alone...
• When employees permanently make long hours...
then
• ... the project normally doesn’t have a defined, accepted and validated project
process. That the project reaches the given targets is implausible.
• With project management alone no project can be steered. There must be
additionally a specific, on the problem matched, project process model.
Without defined procedure
we normally don’t reach the objectives.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
7

Projects in a two-party contract relationship
• Often we come upon situations in major projects, where the management engages
external suppliers (e.g. consulting companies or outsourced IT).
• In this case responsibility between the parties has to be regulated. The ISO 9001
Norm offers an instrument for that.
• Basically responsibility is defined as follows:
– Client:
• „Product responsibility” – is responsible for costs, deadlines and benefits (scope of benefits)
• Project control on the level of „external project management“
– Supplier:
• „Process responsibility“ – is responsible for a “state of the art” project process, which he is able to handle
(ability of repetition)
• Project control on the level “internal project management”
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
8

External and internal project control
• External project control (client)
Planning categories are
– Milestones per phase (deadlines)
• Review documents
• Ready for user test
– Total expenditures, total costs of projects
– Viable benefits (scope of benefits)
– Risk factors
• Internal project control (supplier)
Planning categories are
– Project organization
– Activity planning (per phase)
– Project documentation, result structuring
– Available resources (in particular employees, client and supplier)
– Allocation of employees to activities/results with detailed effort planning (work packages)
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
9

Client organization
Project owner (client)
Project committee
Review team
(experts)
Client project leader
Client organization has
“product responsibility”
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
10

Supplier organization
Supplier
Supplier project leader
Team 1 Team 2
...
Team n
Supplier organization has
„process responsibility“
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
11

Supplier organization
The teams vary depending on project type.
Typically the following team types occur in projects:
– Project office teams
– Change management teams
– Analysis teams
– Design teams
– Front-end-construction teams
– Component development teams
– Cross function teams
• Method specialist teams
• Tools specialist teams
• Data base administration teams
• Test teams
• Technical infrastructure teams
– Acceptance test team
– Organizational implementation teams
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
12

Team composition in a two-party contract relationship
Involvement of
employees
out of the client
organization
Involvement of
employees out
of the supplier
organization
Teams:
– Project office teams
– Change management teams
– Analysis teams
– Design teams
– Front-end-construction teams
– Component development teams
– Cross function teams
• Method specialist teams
• Tools specialist teams
• Data base administration teams
• Test teams
• Technical infrastructure teams
– Acceptance test team
– Organizational implementation teams
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
13

Organization of phases sign-off as central element of the two-party
contract relationship
• Projects are spitted in phases.
• At the phase end the client organization approves the phase results, in order that
the next phase can be started under stable conditions.
• The projects phases are predefined through the project process model. Depending
on project type a different project process model is taken and therefore a different
phase structure as well.
• At the phase end there is a review respectively a test (in the end phase(s)).
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
14

Organization of phases sign-off as central element of the two-party
contract relationship
• Client project leader organizes a review (respectively test) team.
• The review (respectively test) team (experts) checks the design product and gives
recommendation to the project committee.
• The project committee signs off the phases respectively decides, what has to be
changed on the design product.
Through this practice it is ensured,
that the benefit of the design
product is checked by independent experts,
which are not involved daily in the project.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
15

Organization of phase end „Sign off“
for a strategy project
Project setup
Vision and approach
External
Analysis
Gap Analysis
Internal
Analysis
Review
Formulation of strategic options
Selection of strategic options
Review
Implementation planning
Review
Implementation controlling
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
16

Organization of phase end „Sign off“
for a process development project
Review
Review
Review
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
17

Organization of phase end „Sign off“
for an information system planning project
Review
Review
Review
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
18

Organization of phase end „Sign off“
for a standard software implementation project
Migration planning
To-be. bus. processes
To-be activities
Parameterization
Integration tests
Go-live plan
Ref. org. concept
Parameterization
Organization
structure
Conceptual
design
Detailed design
Interface concept
Data migration plan
Implementation
Review
Review
Fail. planning
Org. document.
Interface program
Data input and migration
System documentation
Test develop. system
Review/Test
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
19

Organization of phase end „Sign off“
for a process and systems integration project
IT szenario
Data reqs.
Apps. scenario
Applications list.
Preliminary study
Function reqs.
Interface desc..
Workstep list
Workflow list
Infrastructure plan
Implement. plan
Review
Task list
Tasks chains
Task description
Work step desc..
Concept
Test plan
Authorization policy
Dialog flow diag.
Program design
WF control
Tests
Review
Task prog.
Test
Implementation
Review/Test
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
20

Organization of phase end „Sign off“
for a in-house development project
IS project (Application development General framework
CIO:
Development of IS concepts
( IS concept).
CIO:
Development of information
System architecture
( Information system
architecture).
Organizer/
business unit:
Development of operational
structures and proceedings
( Process development).
Business analyst – design of information relevant model of to-be-business-system
Modeling of information relevant aspects, which are to be covered by the to be attached
Applications (essential data and transactions)
Review
Business analyst – design of external application model
Identification and detailed model of all transactions (incl. dialog), which should be provided by the new
applications, identification and detailed model of data bases.
Review
Software engineer – design of internal application model
Construction of transactions and databases with specific developed tools concrete information technology,
testing of the system.
Review/Test
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
21

Organization of phase end „Sign off“
for implementation
Implementation Planning
Fall-back Plan
Resources concept
Training Concept Data Transfer Concept
Install Set up Test preproduction System
system
setup Syst. Parameter
Create Interface Progr.
Create Data Migr. Progr.
Finalize Organizational
Design
Processes
Org. structure/
Resourcing
Tasks
Templates
Back up Strategy
Create Batchjobs
setup authorizations
Integration testing
In test system Test Cases Test Results
Implementation Plan
Plan Master Data Transfer
Plan Transaction Data Transfer
Finalize Documentation
Org. Documentation
System docu.
Review
Test
Master Data Collection
Training
Install Resources
Review
Fall-back Plan
final.
Backup Strategy
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
22

Organization of phase end „Sign off“
for implementation
Implementation Plan – Final check
Resources.
Backup Design
Simulation Implementation
Master Data Transfer
Fall-back Plan
Downtime Plan
Transaction Data Transfer
Review
System Implementation
Productive System
Interfaces
Tables
Data Migration Integrationstest
Transaction Data
Master Data
Last integration test in productive system
Authorizations
Control
Test cases
Test results
System Transfer to an Business (RUN)
System Doc..
Org. Documentation.
System Release
Review
Productive System
Operating/
Monitoring
Hotline
(Onsite)-
Support
Backup
Continued Development
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
23

Control tasks in the context of analytical quality assurance
Tasks of quality assurance
Review
Test
Audit
Internal
review
External
review
Internal
test
External
test
External
operating
audit
External
operating
audit
SU CL SU CL CL CL
CL = Client, Su = Supplier
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
24

Control tasks in the context of analytical quality assurance
Supplier review/test
• It must be checked,
– If the design product is formally consistent
– If the design product regarding the content is according to the needs
• The check is conducted on the design products, which are required for each project
phase according to the project process model
• Before each external review/test (with client) there has to be a internal review test
(on the level of supplier)
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
25

Control tasks in the context of analytical quality assurance
Client review/test
• It must be checked,
If the design product regarding the content is according to the needs. That implies formal
consistence, for which the supplier is responsible.
• The review/test is conducted on design products, which are required for each
project phase according to the project process model.
• The review/test is conducted by an independent review team, which is not involved
in the project. This review team is organized by the client project leader.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
26

Control tasks in the context of analytical quality assurance
General test levels
6
Acceptance
(„Operations“)
5
User test
(„Acceptance test“)
4
System test
(„Integration test“)
3
2
Application test
(„Chain test“)
Transactions tests
(„Single test“ f. logical transaction)
Programming
runs
parallel
1
Components test
(„Single test“ for service function)
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
27

Control actions in the context of analytical quality assurance
General test levels – case software
6
Acceptance
(„Operations“)
5
4
User test
(„Acceptance test“)
System test
(„Integration test“)
First of all without interfaces;
at the end with all interfaces
to third-party system
3
Application test
(„Chain test“)
2
Transactions tests
(„Single test“ f. logical transaction)
1
Components test
(„Single test“ for service function)
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
28

Control tasks in the context of analytical quality assurance
Client audit
• Method audit
Spontaneous control through external instance, which audits, if the project process
model is applied in the project.
Object of the audit is process conformity.
• Project leadership audit
Spontaneous control through external instance, which ensures, if the project
reaches its targets in the area of conflict regarding
– Costs
– Deadlines
– Benefits (scope of benefits)
Project costs
Object of the audit are corrective measures to close deviations.
Project time
Benefits of design product
(Scope of benefits)
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
29

Control tasks in the context of analytical quality assurance
Client audit
• The audit is normally executed not announced, that means spontaneously.
• It is initiated through the client organization.
• Mostly it is executed by a third-party (e.g. consulting company).
• Each major project is audited regularly (every 6 to 12 months).
• Each audit analyzes and evaluates the project situation and suggests corrective
measures, which are to be executed by project management.
No large scale project without audits.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
30

Constructive quality assurance – ISO 9001
• ISO 9000 series is a quality system standard of the International Standards
Organization, Geneva, which can be applied generally to all products, services or
processes.
• ISO 9001 regulates specifically the product and service production in a two-partycontract
relationship:
„ISO 9001 defines the model for a quality system when a contractor demonstrates
the capability to design, produce, and install products or services.“
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
31

Constructive quality assurance – SEI-Process-Maturity-Schema*
• Target:
Evaluation of performance of suppliers in information system development
• Method:
Analysis and classification of suppliers in the following 5 stages of maturity
– 1: Chaotic process
– 2: Repeatable process
– 3: Defined process
– 4: Controlled process
– 5: Optimized process
*Acc. Humphrey, SEI, Carnegie Mellon University
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
33

Constructive quality assurance – SEI-Process-Maturity-Schema*
• Stage of maturity 1 – „Chaotic process“:
Chaotic „ad hoc“ development process;
„Over-Commitment“ of supplier;
„Stars“ dominate project
• Stage of maturity 2 – „Repeatable process“:
Repeatable development process;
not documented; tradition;
based on experience know how (“We have done it ever like this.“)
• Stage of maturity 3 – „Defined process“:
Development process is fully and consistently documented and is applied like this.
Acc. Humphrey, SEI, Carnegie Mellon University
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
34

Constructive quality assurance – SEI-Process-Maturity-Schema*
• Stage of maturity 4 – „Controlled process“:
The development process is permanently measured in projects for gathering
quantitative figures, which will be used in following projects as basis for planning.
• Stage of maturity 5 – „Optimized process“:
Defined, controlled development process is permanently optimized (between
projects). If optimization was successful the results can be measured on the
quantitative figures.
Acc. Humphrey, SEI, Carnegie Mellon University
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
35

Constructive quality assurance – Project Management Maturity Model
(PMMM)
Level 1
Level 2
Common
Processes
Level 3
Singular
Methodology
Level 4
Benchmarking
Basic Knowledge Process Definition Process Control Process Improvement
Level 5
Continuous
Improvement
Feedback
Common
Language
Source: Kerzner, Project Management
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
36

Constructive quality assurance – Project Management Maturity Model
(PMMM)
• Level 1 - Common Language:
In this level, the organization recognizes the importance of project management
and the need for a good understanding of the basic knowledge on project
management, along with the accompanying language/terminology
• Level 2 - Common Processes:
In this level, the organization recognizes that common processes need to be
defined and developed such that successes on one project can be repeated on
other projects. Also included in this level is the recognition that project management
principles can be applied to and support other methodologies employed by the
company.
• Level 3 - Singular Methodology:
In this level, the organization recognizes the synergistic effect of combining all
corporate methodologies into a singular methodology, the center of which is project
management. The synergistic effects also make process control easier with a
single methodology than with multiple methodologies.
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
37

Constructive quality assurance – Project Management Maturity Model
(PMMM)
• Level 4 - Benchmarking:
This level contains the recognition that process improvement is necessary to
maintain a competitive advantage. Benchmarking must be performed on a
continuous basis. The company must decide whom to benchmark and what to
benchmark.
• Level 5 - Continuous Improvement:
In this level, the organization evaluates the information obtained through
benchmarking and must then decide whether or not this information will enhance
the singular methodology.
Source: Kerzner, Project Management
| 31.12.2006 | Part 5
| Thomas Gutzwiller - Transformation
38