I am charged with implementing quality practices in a government IT (data center) environment. Things are done in a very basic manner, communication is poor, attitude could be better and QA knowledge is very limited. My first task is to start to document process improvement - almost like defect tracking but for process ideas.
After that step I know there is infinite work to do but would anyone with experience be able to point me in the right direction as to how to start and what to do? How to prioritize which processes are of highest importance when I am still learning the environment (400+ people)
Re: Process Measurement
Just for clarity, is your first step to document areas for process improvement? If so, talk to a few key people and you'll have a good start. At my current position, a major communications problem was that there were no documented requirements. Development could start following a hallway conversation between the manager of development and the director of marketing. The result was products that didn't do what anyone expected them to do. So that was a major area of 'pain' that could be addressed with the introduction of a standard requirments template.
Along with that hurdle was the problem of change control. Prior to the introduction of the requirements template, once the director of marketing set things in motion, he could call any developer working on the project, at anytime, and make a change (what a nightmare for testing!). Anyway, we started baselining the requirements, posting them 'read only' on the shared drive, and any requested change had to go through a simple, but structured, change control process. The test group was then made separate from the development organization (as it should be), and the lead tester now creates test plans from the baselined requirements. If a change is proposed, the lead tester is one of the people who MUST be notified.
We are now striving for CMM Level 2; that should help you a lot with "defect tracking for process ideas."
Re: Process Measurement
Bfantina provides some good input. There is a logical flow to process areas as we actually perform them on real projects. Therefore, I usually recommend that development and implementation for improvements be performed in that same logical sequence.
The logical “flow” is as follows:
At the outset of a project, we do Project Planning and initial Requirements Management and allocation. Then we perform Product Engineering (development and testing) using Configuration Management to control work products, Peer Reviews to check work products, Quality Assurance (QA) to check compliance of products and processes to requirements, processes, procedures, and policies; and, Project Tracking (PT) to manage progress of the project as a whole in an ongoing manner. Intergroup Coordination (IC) is always necessary throughout the lifecycle of a project, as is an appropriate Training Program (TP), or at least a Technical Needs and Skills Assessment (TN&SA). Summarily, by defining, documenting and doing all of these things, we are using Integrated Management (IM) in performance of the project.
In addition to addressing process areas in a logical sequence, you probably want to give some thought to your actual Process Improvement Plan which involves the tasks to be accomplished in order to effectively implement improvements. By way of example, I have attached a file with a list of High Level Tasks. This list was created with the CMM as the quality standard and an objective of formal assessment. While you may not be concerned with formal assessment, the steps are nonetheless valid for an effective Process Improvement Program.
If you are interested in using the CMM as a guideline, or even just require additional information on individual process areas and plans, you can check out my latest book, "How To Implement the CMM - Second Edition." It will guide you through each of the tasks listed in the attached file. You can get the book at Amazon.com, other retail stores, or direct at www.businessprocess-solutions.com .
Diane M. Burwick
Re: Process Measurement
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by stuartb:
I am charged with implementing quality practices in a government IT (data center) environment. Things are done in a very basic manner, communication is poor, attitude could be better and QA knowledge is very limited. My first task is to start to document process improvement ...
... How to prioritize which processes are of highest importance when I am still learning the environment (400+ people)
From experience I can tell you that's not an easy job, even with management support and commitment and with priorities identified and agreed.
But, if you want to succeed, you have to start step by step. As you already noticed you need to identify priorities. In my opinion, the best way to do it is to carry out an internall assessment to identify the priorities. How I did it?
First, I developed a list with managers and other key employees from my department and other departments we have worked with. Then I've developed a list with processed to be addressed (existing processes or processes that should exist). Than I thought to some questions to ask about this processes, like: frequency of use, degree of formalization, if the process is actually measured, tools to support the process, frequency of problems, impact of the occured problems - magnitude and area of impact.
After having interviews with the selected employees, I analyzed the results acording the pre-defined criteria and I presented them to management. During a management meeting, the most frequent processes, with most problems and higher impact were selected as priorities, and a plan to fix them was developed. The advantage of this approach was that priorities were identified taking into consideration everybody's concern. Some results were really surprising for some managers, but finally they accepted the conclusions.
How to improve them it's a different story...
... Not even me.
Re: Process Measurement
Daniel is going down the path that I have found most successful when faced with similar challenges. I approach most opportunities just like I approach any system. In general, define the system, identify the requirements, apply proper controls, identify risks and then verify the output or result. A system is made up of functionality that when delivered to a customer provides an intended service. For instance, a bank ATM consists of hardware, software and telecommunications to provide specific banking transactions for a customer.
You identified your system as the Data Center. As with any system you must identify the intended use, who are the customers of the data center. Then identify the main processes (functional areas), this could be applications or processes, e.g., extracts from other systems, data loads, business rule application/validation, data quality, data extracts, publishing data…. What you typically find in a data center is a lot of disjointed processes that do not appear to be related. As with the ATM, you must identify the critical processes (functions) and make sure management is in agreement with your conclusion regarding criticality and priority.
This may be where the direction gets a little fuzzy because you may (quite possibly will) find redundant processes or nonexistent processes. Stay focused on the critical processes, as that is probably where you need to have your strongest structural support. You will usually find that there will be a handful of critical processes that when made solid will provide a sound structural support for the rest of the system.
Quantify your progress: if possible, try and capture a baseline, how are things done today, how long does it take, what is the error rate, what is the restart rate, what is the communication path. This will help you quantify the improvements.
A data center is nothing more than a large system that provides specific services. OK, it is not that simple but changing the view sometimes changes the enormity of the task.
I could go on and on about this but don't wish to add confusion.