Process Management Principles
How to deploy new processes ? Process approach, practitioners attention points, design principles for process documentation and success factors for deploying changes.
Process Approach:
1. end-to-end performance, with relation to customer requirements
2. management of interfaces
3. consideration of processes in terms of added value
4. continual improvement of processes based on objective measurements
Practioners:
- understand the purpose of the process
- position their activities in the overall process structure
- understand requirements and expectations of their internal customers
Process documentation, training, coaching should not only focus on the mechanics (work products, entry/exit criteria, ...)
Design principles for process documentation:
Beware the anti-patterns:
- cookbook: instructions which are too much detailed (creativity killer, maintenance nightmare)
- everything in one place: one process document of 500 pages
- be prepared: describing all possible exceptions
Good principles:
- processes owned by practitioners
- minimal essential info (details in training, tools, mentors, templates)
- software design principles: information hiding and abstraction, low coupling and high cohesion
Three abstraction levels of process documentation
level 1: process structure, framework showing the relationship between the different process, ie. ISO9000 quality manual
level 2: process descriptions
level 3: detailed knowledge: tools, templates, detailed instructions
Deployment of changes:
Focus on training and coaching when deploying new/changed processes, and on supporting the application of processes with templates and tools.
Success factors:
1. Strong commitment from management (it should be their business and personal objective)
2. pragmatic approach
3. process coach in project organisations
4. use lessons learned and risk management
5. empathise and listen
Communication levels:
Not everything that is said is heard.
Not everything that is heard is understood.
Not everything that is understood is agreed.
Not everything that is agreed is applied.
Not everything that is applied is retained.
Process Approach:
1. end-to-end performance, with relation to customer requirements
2. management of interfaces
3. consideration of processes in terms of added value
4. continual improvement of processes based on objective measurements
Practioners:
- understand the purpose of the process
- position their activities in the overall process structure
- understand requirements and expectations of their internal customers
Process documentation, training, coaching should not only focus on the mechanics (work products, entry/exit criteria, ...)
Design principles for process documentation:
Beware the anti-patterns:
- cookbook: instructions which are too much detailed (creativity killer, maintenance nightmare)
- everything in one place: one process document of 500 pages
- be prepared: describing all possible exceptions
Good principles:
- processes owned by practitioners
- minimal essential info (details in training, tools, mentors, templates)
- software design principles: information hiding and abstraction, low coupling and high cohesion
Three abstraction levels of process documentation
level 1: process structure, framework showing the relationship between the different process, ie. ISO9000 quality manual
level 2: process descriptions
level 3: detailed knowledge: tools, templates, detailed instructions
Deployment of changes:
Focus on training and coaching when deploying new/changed processes, and on supporting the application of processes with templates and tools.
Success factors:
1. Strong commitment from management (it should be their business and personal objective)
2. pragmatic approach
3. process coach in project organisations
4. use lessons learned and risk management
5. empathise and listen
Communication levels:
Not everything that is said is heard.
Not everything that is heard is understood.
Not everything that is understood is agreed.
Not everything that is agreed is applied.
Not everything that is applied is retained.
0 Comments:
Post a Comment
Read more about Software Quality at the <<Software Quality Weblog Home