GovernIT

Your Process Improvement initiative or even a simple process definition has failed. You have taken the necessary steps to see that you are not defining a stupid process and provided guidance on how to define processes. It still failed, sob. Once you have gotten over it, read on.

The 3 most common ways you can fail at Process improvement, that I have personally seen are:

1. Blind Adherence to Frameworks

Process frameworks such as CMMI or SPICE are intended as guiding principles to help

you develop processes that, in turn, help you achieve your business goals. Trying to incorporate each and every aspect of a framework without regards to its applicability in your organization can result in bloated processes that no one can or will follow.

Usually, process improvement begins with Gap Analysis of existing processes against the chosen Process Framework. This is where you can take a wrong turn.

Understand the intent behind the Framework when performing the Gap Analysis. One tried-and-trusted practice is to extract the objectives from the process (in CMMI, these are neatly defined in the Specific Goals) and then use them to see if the goals are met by your current processes.

2. Committees

Yes, Practitioner-led process improvement is the way to go. But that doesn’t mean that you try to get “representation from every section” of people into your process definition team! After a certain threshold, an increase in the number of people is only going to hold you back.

From my experience, the magic range is 3-5, but that may vary if you are in a business process improvement scenario. One symptom of a dysfunctional large team is endless bickering over every word and its intent when drafting the process – in one case, there was a 2-hour discussion on using “measurements” vs “Metrics”!

3. Endless Alternates

This can be a standalone issue or an offshoot of the first two. I have seen teams debate over different scenarios which they might face, when the probability of these scenarios occurring is really small! Usually, there are a few critical paths where the teams might need direction and then there is a catch-all section (which is usually an escalation path for more guidance).

This situation arises when

• People don’t trust themselves and others to do the right thing and/or
• Managers are not very forgiving when their teams take decisions using judgement and then mistakes happen. Only a learning environment is a growing environment and without it, you cannot help people become mature. Without mature people, you cannot have a high-maturity organization!

Yes, there are more ways in which you may fail, but I’ll follow my own advice and stop from listing out all other scenarios . That, however, does not prevent you from adding your own experiences in the comments. They may be a bigger cause of failure!

Do share in your experiences in process improvement and of course, subscribe to the blog.

   Send article as PDF   

The first part of this series provided an overview of the PMO, types of PMOs and typical functions.

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

This post looks at the Quality Management/Assurance responsibilities of the PMO.

Quality Management is a less-emphasized function of the PMO. In large IT organizations, primary Quality guidance is provided by a centralized Quality function and actual implementation guidance by the PMO. For smaller IT organizations, the PMO.

However, it is important that the PMO incorporate the Quality Management aspects into its guidance and governance systems, since process-orientation can bring in discipline and streamline all activities in the Programs/projects.

The key responsibilities of a PMO for Quality Management include:

Setting up quality standards if none exists or tailoring organizational standards
Provide guidance on defining acceptance criteria to measure successful completion of the project
Provide guidance on setting up Program and project specific metrics for monitoring, tracking progress and quality
Schedule, conduct and review Program and project audits to ensure they are following the guidance provided by the PMO.
These aspects can be detailed out in a Quality Management Plan. A well-structured QM Plan can help the Program/Project adhere to the accepted practices in their projects. In addition, the PMO may also provide
Quality management support to projects through a dedicated team of people.

A typical QM Plan will have the following Table of contents (sections):

• Reference to organizational processes (if available)
• List and reference to any adaptations to the organizational processes, templates and checklists
• List and reference to program/project specific processes, templates and checklists
• List and reference to all standards/guidelines (including technical, industry-specific regulations, domain etc)
• Release Reviews performed by the Quality function before any customer/production release
• Program/Project specific metrics and tolerances
• Work product reviews that will be performed by people in the Quality function
• Tools and techniques used for Quality activities
• Defect prevention, causal analysis activities and techniques
• Reports and Dashboards
• Frequency and timing of project reviews and audits by the Quality function

If you have implemented the Quality Management function as part of the PMO, we would love to hear your experiences and challenges.

   Send article as PDF