Process Implementation

Abstract.

Process improvement requires two major steps. First, new processes must be defined. Second, the organization must begin to use those new processes. The literature has provided good guidance on writing new processes, but very little has stated clearly what actions must be taken to implement and then institutionalize the use of the processes. This paper provides a list of implementation and institutionalization actions that organizations should consider estimating, planning, and performing to ensure the new processes are used. Those actions fall into the categories of training, ensuring management support, obtaining a measurement baseline, auditing the use of the processes, collecting and maintaining a library of process assets, tailoring the processes, improving the processes and appraising the processes.

Introduction

Writing new processes may be the easy part of process improvement. This can be a very depressing thought to those who spend years on process action teams (PATs) and systems- or software-engineering process groups (SEPGs).  However, once those processes are defined, documented, and even communicated, much work remains.

Each person working in the implementation organization will need to:

• Access the processes
• Understand all the processes at a top level
• Understand in detail the processes that he or she performs

Managers must

• Understand all the processes at a top level
• Understand the project management process(es) in detail
• Understand how to manage the organization using processes
• Access historical measurement data for all processes.

These activities require training and more.

Manage process implementation as a project

Nearly all good process improvement advice emphasizes that process improvement must be run like a project, with a project manager, plan, resources, and the other essentials for any project. The need for a set of project processes continues after the processes are defined into the implementation phase. The organization must create a work plan that includes all of the following tasks, an appropriate time frame for each, and the resources needed.  The process improvement group should use a tailored version of the organization's project management process to track the progress of the process improvement effort against that plan.

Obtain management support

Ensure management supports process use. As described in [Sheard 2001], senior management commitment can make or break any change effort. One very important set of senior management actions is to ensure that middle management also supports the process improvement effort.  Too often it is the many layers of program and line management between practitioners and managers who sabotage the use of new processes.

• 1) Determine how we will be able to tell if management supports process use (employee surveys? Interviews? Measures? Do we need other indicators such as to require certain items in program status reviews and verify that they are there and correct? How about whether managers acknowledge process use to each other?) What is the connection between managers fully supporting process use and their performance plans?
• 2) Determine who all the project managers are. Verify they are using work plans.
• 3) Establish a resources data base or other way of accounting for who's been assigned to do what tasks on projects, programs, segments, and other efforts. Be sure that your project management process states how to allocate people to a project, and how to un-allocate them when they are no longer on the project.
• 4) Ensure that managers use the resources data base - everyone on their project is so noted in the data base.
• 5) Periodically check that people really are doing what it says in the data base they are doing, and they aren't over 100% committed.

Establish policy

• 1) Establish policy for following the organization's processes.
• 2) Repeat for each other organization that will be using the processes
• 3) Determine how you will know if policy is being followed, and actions to take if not being followed.

Establish measurement baseline for how much effort processes take to enact.

• 1) If needed, determine a way for people to record how they spend their time (note: this problem was solved three or four decades ago by defense contractors, but many government organizations have not yet addressed it! Their time is often listed only as "work" or "leave.")
• 2) Determine the things that you want people to split their time up into. Processes? Activities? WBS elements? Test that these categories are usable and people won't be putting a majority of their hours into "Other." (note: even though contractors have established ways of recording time, they don't necessarily have the flexibility to modify the charge numbers to allow recording of process-related activities such as "peer review meeting" or "requirements rework.")
• 3) Incorporate the things you want to measure into the tool for recording time.
• 4) Plan what you're going to do with the data when you get it (how you will do all the steps below). Make analysis templates, e.g. Test with fake data. Do they meet the needs you have for the information? Note: [PSM 2001] provides excellent guidance on measurement templates.
• 5) If needed, train people in recording time. (Government institutions or others encountering this for the first time will have a lot of work to overcome the "This is the worst thing I've ever had to do. It treats me like a supermarket clerk, not a professional" opinions of people who don't fill out timecards today.)
• 6) Collect the time. Validate the data. Chase down data points that fall outside the expected ranges (which you have determined in advance), and correct input data that was in error. Store it. Analyze it. Report on it. Decide what you want to do with it: for example, change how the data is analyzed or collected.

Train employees and managers

All employees and managers must understand the new processes. This is different from domain-based training such as use of a tool, a programming language, or a requirements capture method. This training introduces the processes to the organization in a manner that is efficient for those who are being trained. By this is meant that the training highlights differences in the new processes from what is currently done today, and to the extent possible, is tailored for the specific audience receiving the training.

Those planning the training need to consider including the following steps:

• 1) Find out how many people there are, their names, their jobs (i.e. which processes they need to know in detail) and therefore what training or what waivers they will need.
• 2) Develop waiver criteria and procedure.
• 3) Obtain funding to perform such training (both the hours for the trainer and the hours for the trainees)
• 4) Develop success criteria for the training. How will you know it's effective? Use these in the evaluation step below. Determine what corrective actions should be taken regarding those who do not pass.
• 5) Develop the training, including any needed quizzes or tests. Training should include an introduction to capability models and why the current model was selected, as well as how it's being used.
• 6) Pilot the training and the quizzes or tests, and improve them.
• 7) Plan delivery of the training. Will this be project by project, process by process, broadcast, web-based and check off when you've finished, or what?
• 8) Schedule the training, and ensure the people who should be there are going to be there. Get project and individual agreement that the people will take the training.
• 9) Grade tests and record those who have successfully learned the material.
• 10) Plan any remedial training required.
• 11) Reschedule training for those who do not attend, or those who do not sign up.
• 12) Evaluate when changes need to be made to the training (either the training doesn't do the job, or the processes being trained have changed). Plan what "regression training" needs to be done. Ensure it happens.
• 13) Continue to provide training to new employees, those who are taking on a different job so they need different detailed training, and refresher training in response to audit actions suggesting that people forgot aspects of the processes.

Tailor processes

• 1) Finalize tailoring guidelines that you wrote when you were writing the processes.
• 2) Assign one or two process people to each project (or other effort requiring a work plan) to help them tailor the processes for their project. Escort the tailored processes through SEPG (or dedicated subset) approval.
• 3) Improve tailoring guidelines based on measurements of how well the projects understand them and how easy the processes are to use.

Maintain process assets

• 1) Determine where you will store process assets as they are created.
• 2) Establish a place for process change requests and for working copies of the changes.
• 3) Plan for periodic review of the PAL, both how well it's being used, how organized it is, how current it is (are there old copies hanging around?)
• 4) Evaluate PAL and respond to needed changes.
• 5) Determine how you will measure goodness of the PAL. (Usage numbers? Audits? User satisfaction surveys?) Measure it and respond.

Ensure processes are being used

• 1) Develop a process auditing capability. Decide what kind of audits will be done for each process, and what will the auditors verify.
• 2) Document the process-auditing procedure (if not already documented as part of QA process).
• 3) Decide who will audit processes, and train them.
• 4) Establish a plan for which processes are going to be audited, and how often, both per project and organizationally.
• 5) Decide what you're going to do with audit results. To whom will they be reported? What are the standard elevation paths if the audits show problems? How are you going to collect and act upon the inevitably process improvement suggestions.
• 6) Train people in how to answer auditor questions. The should learn to answer specifics of this process use, not the whole history of the product, and should not feel impelled to say yes. Say no if it's true, and the short answer of why not.
• 7) Schedule audits.
• 8) Do audits, collect information, process as per plan, report per plan.
• 9) Improve auditing procedure as needed.

Learn lessons:

• 1) Figure out how you're going to learn them and share them
• 2) Roll out that process
• 3) Provide status on how well lessons are being recorded and transmitted

Improve processes

• 1) Define the role of "process owner," estimate resources, and sign people up to be process owners for all processes.
• 2) Decide who's going to review proposed changes and who's going to implement them in new process descriptions (PAT? SEPG? Separate process review board? Other?)
• 3) Determine the charter and meeting plan for the review board that approves process changes. How much of this board should be project representatives as opposed to the SEPG?
• 4) Determine how users will request process changes when they detect a problem.
• 5) Establish a process change request form and procedure for accepting, sorting, reviewing, and responding to them. Be sure you will provide feedback to originator about what you did with each suggestion.
• 6) Establish a process for changing the processes and rolling them out, including the training. Will you do them all at once, periodically (say, annually) or each time a change is approved? If you do them one at a time, what happens with interfacing processes? If you do them all together, will you have sufficient proof that the change will work?
• 7) Schedule review board meetings
• 8) Solicit process improvement suggestions.
• 9) Analyze impact of each change not only on project execution but also on training of this process. Will anyone need retraining? How will the training change? Should there be an update memo, perhaps?
• 10) Hold review boards. Determine whether proposed changes will be implemented. Plan the change and rollout. Approve final documents.
• 11) Pilot process changes if they are big or risky enough.
• 12) Update training and roll out per the roll out process.

Appraise the organization

• 1) If not already done, verify that the processes as documented meet the needs of the model and the organization.
• 2) Determine when you will want mini-appraisals to verify that a process is being implemented. These could be periodic but more likely will occur after training, per program, etc.
• 3) For each mini-appraisal, plan and prepare.
• 4) Perform mini-appraisal
• 5) Respond to mini-appraisal.
• 6) Plan full appraisal. This includes engaging official assessor, if desired, and using that assessor as part of a dry run appraisal, if desired.
• 7) Perform full appraisal. Ensure widespread upper and middle management attendance.
• 8) Celebrate accomplishments, set new goals, and continue.

Conclusions:

While developing usable processes for an organization, it seems that implementation by comparison will be easy. However, many steps must be done to ensure that there aren't any surprises. This paper lists the steps needed and provides guidelines so that a process group can estimate and plan the implementation effort.

References:

Richard Waina, Software Technology Conference 2002 tutorial, on GQM

Sarah Sheard International Council on Systems Engineering 2001 paper, Senior Management Commitment.

Sarah Sheard, Evolution of the Frameworks Quagmire, IEEE Computer July 2001

Sarah Sheard, "How do I Make My Organization Comply with Yet Another Maturity Model?", Crosstalk, February 2002. Is there a paper on how to do process training?  Should I write one?

Dave Card, Process measurement

Practical Software Measurement

Reference on process audits

Reference on doing PI like a project

Reference on PI policies?

Reference on the variety of appraisals?  (Maybe FAA)?

Paul Popick and Craig Smith on Lessons Learned.