Xerox is the kind of company where it s easy to wake up one day and find that you ve been working there for 10 or 20 years . However, unlike many of my peers at Xerox, I spent much of my professional life with the company, but not all of it. Prior to working for Xerox, I worked for Grumman, Lockheed, Unisys, The Travelers, and for myself . I had experiences with which I could compare and evaluate the Xerox experience. (My personal satisfaction with Xerox often stemmed from my knowledge of the horrors that lie just outside the protective confines of the big, red X.)
In Xerox, as in other organizations, there are EBPs that either evolved naturally or were planted and cultivated in the environment by some quality-oriented initiative such as Total Quality Management (TQM) or the Malcolm Baldrige Award, which Xerox won in 1989. In many instances, these EBPs become so entrenched in the environment that they become, over time, as essential but as unnoticeable as the air we breathe. In CMMI terms, these EBPs become institutionalized.
If you look at a forest from one perspective, you might only see its tall, strong trees. They re all slightly different and sometimes internally competing for resources. You can view an organization the same way. The trees are the business units, departments, divisions, or product lines. Or, viewing the organization through a CMMI lens, you might see requirements being managed, projects being planned and managed, things being placed under configuration management (CM), and so on.
In both the forest and the organization, what you don t see from a more natural perspective are those things that bind all the components of the system together. In the ecosystem view of the forest, a studied look reveals the moss on the same side of all the trees, the movement and transfer of water and air, the recycling of the organic matter that makes up the forest floor for nutrients for the trees, the seeding of new growth and renewal, often through the death of a tree or a part of the total system. (For greater insight into applying a systems view or systems thinking to process improvement, read Chapter 4 ” Process Improvement Strategies that Work.)
In a systems view of an organization, you will find the EBPs that integrate and hold together the boxes on the organization chart or the systems development processes. The forest is not just a collection of trees and a business is not just a collection of departments or processes based on CMMI.
So, what s inside a CMMI Level 1 organization and what are these EBPs? The answer is astonishingly simple. Most of the EBPs are activities or structures that you will find in just about any business organization in the world, whether or not it is engaged in CMMI-based process improvement.
I haven t found all of them yet, but here are the EBPs that play a significant role in CMMI-based process improvement:
Writing and documentation
Previous or concurrent quality or improvement initiatives
Project management discipline
Organizational standards
Training programs
Meeting management
Measures and measurement activities
In CMMI, SEI made a significant improvement with the Continuous Representation by categorizing the process areas into logical groupings: engineering, project management, process management, and support. You could almost consider the Continuous Representation categories as meta process areas.
Each EBP is yet a different kind of meta process area. Instead of grouping similar CMMI process areas, they group activities which act as common threads running through all the process areas. The common threads of the EBPs are interwoven through the CMMI process areas and can be used to weave together an integrated approach to using an integrated model for systems process improvement. (See Figure 1.2.)
Let s take a closer look inside each of the EBPs and see how you can use them to improve your organization s process capability or maturity level using that which already exists in the organization.
The following is a random list of activities or things you might witness in a typical system engineering organization:
Project plans
Database creation
Software design document
System requirements updates
Employee performance reviews
Training slides
Contracts
Written status reports
Processes and procedures
Template or form development
Meeting agendas
Program reviews
What do all of these things have in common? They certainly don t all fit neatly into one CMMI process area, generic goal, or even one process category. Here s the common denominator: they all involve writing or the existence of some form of document. (Note: A document does not have to be on a physical sheet of paper.)
Well okay, so why is writing and the ability to create documents so important to a CMMI effort? Two reasons: (1) most of the effort and cost associated with a CMMI process improvement project will be spent writing, editing, or revising some kind of document and (2) the availability of this skill is hugely overestimated in most organizations.
Let s first look at just how pervasive the work of writing or creating and maintaining documents is in the American workplace. I conducted a survey of 80 people chosen more or less at random. Their roles in their respective organizations represent most of those you would find in a typical systems organization. The roles surveyed include software, hardware, and system engineers , project and program managers, facilities and logistics support personnel, purchasers and contract personnel, process improvement managers/leads, senior managers, executives. The survey asked the participants to estimate the approximate percentage of their work time they spent in each of the following activity categories. Each category was defined and included examples of activities that fit into that category.
Thinking: Formulating or manipulating ideas or thoughts entirely in your brain, but not performing any physical work or producing physical outputs.
Writing: Includes revising, editing, formatting, or modifying any type of document that consists primarily of words.
Talking: Speaking to others and listening to others speak but not performing any physical work or producing physical outputs.
Work other than writing: This category includes activities such as writing software, building or assembling hardware, performing tests, monitoring network activity, etc.
The survey participants were given other guidance. For example, writing and talking also involve thinking but neither thinking nor talking necessarily includes writing. So, if thinking or talking also concurrently involved creating or changing any type of document, the participants were instructed to count the time in the writing category.
If asked if writing was their job, most of these people replied, no. Yet people s responses to the survey suggest that writing is a big part of their work. The amount of effort spent creating or changing documents is likely to be even greater in process improvement work. No matter which phase your CMMI process improvement effort is in, people are writing. In a baseline appraisal, people are writing observations and findings. In process improvement planning, people are writing process improvement plans and subplans. After planning, people are creating or modifying policies, processes, procedures, and process implementation work products. In implementation, they re revising the process assets, creating training materials, sending mail notes to systems project personnel, and writing status reports. Come appraisal time again, they re writing an appraisal plan and then documenting observations and findings. Get the picture?
Now we get to the number two reason why writing and documentation are so important: these skills are usually lacking in organizations. Maybe the problem is that writing is either not viewed as a learned skill or that we just assume that everyone can write; we take it for granted. Ironically, we all tend to agree that writing software is a learned skill, that designing a database architecture is a learned skill, and even that managing people well is a learned skill. Yet we don t seem to give very much weight to the skill that is fundamentally critical to doing all of these and other jobs ” written communication. After all, anyone with a high school education can write, right? No.
If you re in charge of your organization s process improvement effort and you re really lucky, you ll get to select the people who make up your process focus group, the SEPG or whatever you call it. You ll pick the best and the brightest people who represent and can speak for their functional areas: engineering, design, project management, quality assurance, configuration management, senior management, contracting, security, etc. You ll bring these really bright people together and the first thing you ll ask them to do is something they do not do well ” write. You have practically set these bright people up to fail and, worse yet, look or feel incompetent.
This is exactly the scenario in one of the organizations with which I ve worked. They managed to pull together some of the best people in the organization to form the enterprise-level process focus group. Based on a plan, these people started developing a really good, comprehensive yet tailorable standard set of processes. Prior to piloting their processes, they convened several times to peer review their own work. As indicated by the defect logs that were generated from these peer reviews, the vast majority (about 70 percent) of the defects and the vast majority of the rework and revision effort was expended on defects that could have been prevented if they had previously adopted some simple documentation standards for the process assets. Yet who knew or thought to recruit a technical writer or documentation specialist for the SEPG? I know now, but I didn t know then. Now you ll know.
There are two simple things you can do to reduce or eliminate the pain and cost of rework related to writing and documentation:
Find and recruit writing and documentation skills for your process focus group. Although technical writing or technical publication departments have become all but extinct, you can still find pockets of competence in this area in most organizations. Get help from such people for all of your CMMI work and get it early.
Many organizations have some documentation standards although ” again ” such standards might be a useless relic if no one abides by them. If you can t find any homegrown documentation standards, go elsewhere and get them for free. Once you have format standards ” you know, headers, footers, type face, headings, margins, all that stuff ” don t stop there! What makes documents, especially processes and procedures, either work or not work for people are their contents.
So, before you get highly paid people to sit around and fret about type sizes and acronym use, put their minds to something really useful like determining the content standards (what goes in the various process-related documents), the logical sequencing of sections, the applicability and scope of policies versus processes versus procedures, the use of graphics or illustrations, etc. You need to ask and answer questions like:
What makes a process versus what makes a procedure?
What goes in a policy?
How does a form differ from a template?
And you need to write down those standards. (To address these specific questions, read Chapter 5 ” Five Critical Factors in Successful Process Definition.)
One of the more common features of the American corporate landscape is the continual and often simultaneous implementation of multiple process, product, quality, and strategic initiatives. Some companies and organizations will jump on almost any quality or improvement initiative that appears to be the trend or what the competition s doing. Some companies even take on multiple initiatives simultaneously , with corporate staffers sitting around dreaming up glossy materials to convince the workforce that this new thing will be really good for them and the company. The staffers in HQ can often have offices just a few feet distant from each other, yet it doesn t seem to occur to them to talk to their peers to find out if their separate initiatives can be somewhat integrated to save the company time, money, and employee aggravation. The observed approach appears to be, No, let s just leave the simultaneous implementation of our multiple initiatives up others. We re the idea people.
Modern managers ” in both the government and private sectors ” are constantly tasked with having to integrate quality and improvement concepts and practices into their work, while still producing high quality deliverables faster and at lower cost. In the words of one parable, the modern leader is expected to sharpen the saw while simultaneously continuing to cut the trees faster and better. Today s leaders are inundated with initiatives. Six Sigma, Lean Sigma, Critical Chain, CMMI, ISO, Balanced Score Card, enterprise resource planning (ERP) and customer relationship management (CRM) are just a few of the larger initiatives on today s business landscape; tomorrow there will surely be more.
As this book is being written, Natural SPI is working with a government organization in this exact situation. The senior manager has been told by his bosses to implement the theory of constraints as described in Critical Chain, [7] but also to incorporate CMMI practices, Personal Software Process SM (PSP) practices, and Team Software Process SM (TSP) practices into their system delivery operations. To start helping this client, we are building an array that will help him sort out which aspects of the multiple initiatives will help the organization achieve its goals. The first layer of understanding will look something like the illustration in Figure 1.3.
In the array in Figure 1.3, many of the typical business perspectives or areas of focus are shown across the top. These are the categories for grouping business goals that support the enterprise s strategy. The rows represent some current quality, process, or productivity improvement initiatives (Implementation Approaches). The partially shaded, fully shaded, or not shaded cell at the intersection of a perspective and an initiative represents the relative amount of benefit that perspective can reap from implementation of the initiative.
Through diligent research and dialog with experts, we are able to help this client to at least have a goal-level perspective of which parts of the different initiatives his organization should start looking into. Of course, there are more layers beneath this initial cut, but it does offer the advantage of saving the client the effort of having to read and internalize several thousand pages of models and academic books.
During my nine-year tenure at Xerox, the lower levels of the workforce, which included me, had to figure out how to execute Leadership Through Quality (LTQ), Software CMM-based process improvement, Integrated Supply Chain, and Time-To-Market (TTM). Moreover, there was constant pressure to integrate the principles and practices of these initiatives into our work, while continuing to develop and deliver products and while worrying constantly about the next layoff . In the Application Services Division (ASD) of CSC, we were trying to force fit CMM to everything the division did from common off the shelf (COTS) integration to pure helpdesk functions, while implementing the strangest form of a balanced scorecard I ve ever seen, while the division president flew around and made everyone read Who Moved My Cheese ? [8] And the executives and senior managers of these enterprises were constantly wondering why we couldn t get better products out faster or keep their customers happy. We were literally improving ourselves into oblivion and you don t have to be a Harvard Business School grad to figure that out.
Corporate quality and process improvement initiatives have been around for a long time, at a minimum dating back some 20 to 30 years to the work of Dr. W. Edwards Deming and Joseph M. Juran. Most notably, three modern-day programs or initiatives require work that is often closely related to CMMI-based improvements: ISO 9001:2000, [9] the Malcolm Baldrige Quality Award, [10] and Six Sigma. [11] The synergy between ISO 9001 and CMMI and Six Sigma and CMMI are discussed in this section.
Before initiating a CMMI-based process improvement project, ask around and try to identify other quality or improvement initiatives that are either currently in progress or have been undertaken in the past. If ISO, the Malcolm Baldrige Award, or Six Sigma is in the organization s present goals or recent history, you are bound to find management and engineering practices already existing that will map well to CMMI. Leverage what these other programs have already accomplished. Don t undo what they have built only to spend time and money rebuilding something similar.
The following sections will give you enough information on the synergy between these separate initiatives to conduct a more thorough investigation on your own. A more thorough comparison of CMM and ISO and the Malcolm Baldrige Award can be found in Michael O. Tingey s book, Comparing ISO 9000, Malcolm Baldrige and the SEI CMM for Software . [12]
At any rate, the main idea is to spend a little time investigating the organization s history in improvement efforts. You can sometimes find a wealth of tribal knowledge and engineering practices that you can leverage.
Natural SPI, my consulting firm, enjoyed the wonderful opportunity of working with a very large-scale CMMI implementation on an Air Force program called J-Tech. J-Tech was essentially a range interoperability contract and involved implementing CMMI-based systems engineering improvements at four USAF test and training ranges. The contract called for the prime contractor ” JT3, LLC ” to achieve a CMMI maturity level and to be compliant with ISO 9001:2000.
From the outset of the contract, one of the most common questions people asked the JT3 CMMI Program team went something like this:
I m already doing this ISO stuff, so how does CMMI fit in? And are you going to make me do duplicate work to satisfy both models?
Usually some time after the respondent overcame the initial urge to snap back, oh quit your whining, there came a more thoughtful, constructive answer. The better answer was:
The CMMI model and ISO standards correlate and complement each other much more than they clash . The JT3 CMMI Program Team understands that and, with your help, will make sure you don t become a casualty of a models war.
Before people get all riled up about the differences between CMMI and ISO 9001:2000, get out in front of them by pointing out what they have in common. First and foremost, both of these things are abstractions of reality; CMMI is a model for operational excellence and ISO 9001:2000 is a standard for quality systems. As abstractions, both models/standards (let s collectively call them a modard ) identify practices that are commonly found in successful systems and service delivery organizations. They define what people do or what occurs in organizations that demonstrate measurable operational excellence. Neither modard explicitly tells people how to go about implementing the practices they define. In today s organizations, the job of determining how people will improve the way they work using the modard requires people to engage their brains ; apply some intelligent interpretation to defining how the modard fits in the environment; and figure out ingenious ways to implement practices that satisfy ISO, CMMI, and actually help people do their jobs more effectively and efficiently .
There are more similarities. A review of mappings between ISO 9001:2000 and the CMMI from three sources indicates that cross-correlation of ISO clauses to one or more CMMI practices ranges from 60 to 90 percent. [13] [14] [15] That means that at the concept level there is overlap between the goals or intent of CMMI and ISO. This in turn means that if there s poor implementation of the modard in the organization, you could end up doing similar and redundant tasks or activities trying to satisfy both ISO and CMMI. So, how do you avoid creating a giant pile of documents that make you go off and perform two different things to achieve the same goal?
In the case of JT3 s CMMI Program, the ISO effort had gotten a head start on the CMMI work. The people responsible for ISO-based implementation had developed numerous practices, which were policy and procedural documents. Having these practices in place reduced the amount of work for the JT3 s CMMI process focus group (called JPEG for JT3 Process Engineering Group). In many cases, all JPEG had to do was map the existing practices to CMMI or make incremental revisions to the practices to include systems engineering work and activities. Making minor revisions is always easier and more cost-effective than defining a process from scratch. The leadership of JPEG was also smart enough to include in the JPEG membership people who worked in the organization that lead the ISO initiative. These individuals participation in both the CMMI and ISO realms played a key role in minimizing overlap and duplicate effort.
Are there some differences between CMMI and ISO 9001:2000? Sure, nothing s perfect. For starters, ISO 9001:2000 is 32 pages in length; CMMISE/SW/IPPD/SS, Version 1.1 is over 700 pages in length. Ostensibly, there might be a difference in the level of detail provided in these two documents. ISO 9001:2000 defines requirements for a quality system whereas CMMI provides implementation guidelines (e.g., typical outputs from a process) for each practice in each process area. The other major difference is that ISO 9001:2000 defines a minimum standard for organizations to achieve, whereas in the CMMI, different levels of operational excellence are defined via either process capability or organizational maturity levels (Continuous versus Staged Representations).
And, this story could go on and on and bore you to death with academic discussions about the similarities and differences between ISO and CMMI. But that s all it is, academic discussion. What should matter to you is that, in the end, you re not so buried in processes and procedures originating from the modards that you can t do your job and satisfy your customer. Find the synergy. Build the links and mappings. Don t duplicate effort.
This section will not teach you about Six Sigma, what it is, and how people use it. There are ample references on that topic. This section describes some of the relationships between Six Sigma and CMMI and how your organization might leverage those relationships if both these initiatives are underway. Again, when an organization is dealing with multiple quality or improvement initiatives, the goal is efficiency through limiting duplication of effort.
In a nutshell , Six Sigma is a management philosophy for improving organizational performance by reducing or removing variation. [44] The general business benefits touted by Six Sigma are greater process performance predictability, less waste and rework (lower cost), products and services that perform better and last longer, and happier customers. Hmm, those first two benefits ” greater process predictability and reduced waste and rework ” sound familiar, don t they?
Six Sigma is implemented via a path known as Define, Measure, Improve, Analyze, and Control (DMIAC). Within the CMMI process areas, there are practices which can be used to support the implementation of DMIAC. For example, the CMMI s Measurement and Analysis (MA) practices can be used to provide information in the Six Sigma Measure phase of DMAIC and CMMI s PMC, IPM, and QPM process areas can be leveraged in the Control phase of Six Sigma s DMAIC.
There are other comparisons between CMMI and Six Sigma. In general, CMMI identifies what activities are expected in a process. Six Sigma helps make those activities more effective and efficient. So, for example, an organization will use CMMI to make sure it is implementing activities such as estimating and risk management to improve overall project planning. Six Sigma can be used to continually improve the accuracy of estimating and risk management. CMMI-based process improvement efforts often have little impact on business results such as fewer defects, lower cost, and higher efficiency, whereas Six Sigma activities are totally driven to yield measurable business results in these areas. Six Sigma can provide specific tools for implementing the CMMI practices in DAR, CAR, and QPM. Six Sigma is weak in terms of establishing an improvement infrastructure whereas this is one of CMMI s strengths through OPF, OPD, OT, and the Generic Practices (GPs).
Many CMMI practices ” even those defined in the Process Management, Engineering, and Support categories ” involve basic project management practices. Much of the what to do and how to do it of project and program management is also defined in the Project Management Body of Knowledge (PMBOK ), [16] an extensive repository of project management information established by the Project Management Institute (PMI ). PMBOK is used by thousands of project managers, many of whom are also involved in the planning and implementation of CMM or CMMI-based process improvement. The challenge for project managers is working with PMBOK and CMMI without duplicating effort to accomplish common goals and tasks.
This section gives you an overview of the synergy for reuse between CMMI and PMBOK. It discusses a case study in which both CMMI and PMBOK were jointly used to define an effective enterprisewide project/program management process. Specifically, what you can learn from this section is practical, actionable information on three main aspects of CMMI-PMBOK synergy: [17]
A project management view for process improvement
CMMI and PMBOK similarities and differences
CMMI and PMBOK strengths and weaknesses
There have been times when I have asked someone how their process improvement project is going, and the response has been along the lines of, what do you mean, ˜project ? or it s not a project. So then I ask a few more questions like:
Did your CMMI effort have a start date?
Answer: Yep.
Does your CMMI effort have an end date?
Answer: Yep.
Does your CMMI effort have a schedule, estimated and allocated resources, and will it deliver something?
Yep, yep, yep.
Are there risks to achieving your goals?
Yep.
So, how can your CMMI effort be anything but a project? And if you accept that it is a project, why would you not use proven project management methods , practices, and techniques to manage it?
Just because a process improvement project delivers a process system and doesn t deliver software or software- intensive systems, there s no reason you can t use the basic concepts and practices of good project management. When you build and deliver a process system, you re delivering something internal to the organization that will help people do their jobs more effectively and efficiently, just as e-mail and voice mail systems helped people communicate better in the workplace. Both the applicable CMMI practices and PMBOK can help people with process responsibilities effectively plan and manage their process improvement project. How to better plan and manage your process improvement project is described in detail in Chapter 3 ” Managing the Process Improvement Project.
There are both similarities and differences between PMBOK and CMMI. The primary difference is that CMMI contains practices that provide guidelines applicable to almost the whole spectrum of system engineering and management activities whereas PMBOK s focus is on project management.
The similarities between PMBOK and CMMI are strong in the process areas in the Project Management category of the Continuous Representation, particularly Project Planning (PP), Project Monitoring and Control (PMC), and Risk Management (RSKM), with PMBOK being more rich in information on risk management than CMMI.
In the JT3 process improvement program, JPEG established process improvement teams, with one of the teams devoted to defining processes and work products for all the PAs in the Project Management category. This intuitively makes a lot of sense because of the strong inherent interrelationships between planning a project and then executing the plans. The Project Management (PM) team was fortunate enough to have two PMI-certified Project Management Professionals (PMP ) as members .
The team ultimately designed four major project management processes and associated implementation work products structured along the lines of PMBOK s four PM phases: (1) Project Initialization, (2) Project Planning, (3) Project Execution, and (4) Project Closure. The architecture for the project management processes was defined in a sophisticated Excel spreadsheet that correlated many process components including the process task or subtask, primary responsibility (by role) for performing the task, entry criteria and inputs, process implementation work products, and exit criteria and outputs. For each project management task or subtask, the table also identified the correlating CMMI practice and PMBOK practice. Table 1.1 shows an outline of the JT3 PM process and the CMMI and PMBOK relationships.
Implementation Process | CMMI Practices | PMBOK Practices |
---|---|---|
Phase 1: Project Origination | ||
Originate/start project | 5.1 Project Initialization | |
Initially scope and authorize project | PP SP 1.1, SP 1.2 | 5.2 Scope Planning 5.3 Scope Definition |
Phase 2: Project Planning | ||
Develop Project Management Plan(s) | PP SP 2.7 | 4.1 Project Plan Development |
Plan project life cycle | PP SP 1.3 | 2.1 Project Phases and Life Cycle |
Plan project process (tailored JEEP) | IPM SP 1.1 GP 2.2 for IPM | 3.4 Customizing Process Interactions |
Estimate project effort and cost | PP SP 1.4 | 6.1 Activity Definition 6.2 Activity Sequencing 6.3 Activity Duration Estimating 7.1 Resource Planning 7.2 Cost Estimating |
Develop project schedule | PP SP 2.1 | 6.4 Schedule Development |
Plan project resources | PP SP 2.4, SP 2.5 GP 2.3 and GP 2.4 for PP, PMC, RSKM, and SAM GP 2.4 | 9.1 Organizational Planning 9.2 Resource Planning |
Plan project stakeholder involvement | PP SP 2.6 GP 2.7 for PP, PMC, SAM, RSKM | 2.2 Project Stakeholders 10.1 Communication Planning 11.1 Risk Management Planning |
Plan project risk management | PP SP 2.2 RSKM SP 1.1, SP 1.2, SP 1.3, SP 2.1, SP 2.2, SP 3.1 | 11.1 Risk Management Planning 11.2 Risk Identification 11.3 Risk Analysis ” Quantitative 11.4 Risk Analysis ” Qualitative 11.5 Risk Response Planning |
Plan project monitoring, control, and reporting | GP 2.2 for PMC GP 2.8 for PP, PMC, RSKM GP 2.10 for PP, PMC, RSKM | 10.1 Communication Planning |
Plan vendor or COTS acquistion | SAM | 12.1 Procurement Planning 12.2 Solicitation Planning |
Plan work product verification and requirements traceability | VER | |
Plan work product validation/testing | VAL | |
Plan project measurements | MA SP 1.2, SP 1.3, SP 1.4 GP 2.8, GP 3.2 | |
Plan project CM/DM | PP SP 2.3 GP 2.6 | |
Plan project QA | GP 2.9 | 8.1 Quality Planning |
Review and approve project plans | PP SP 3.1, SP 3.2, SP 3.3 GP 2.2, GP 2.3, GP 2.4, GP 2.5 | |
Acquire resources and budget | PP SP 3.2 GP 2.3, GP 2.4 | 7.3 Cost Budgeting 9.2 Staff Acquisition |
Phase 3: Project Execution | ||
Monitor and report project performance against plans | PMC SP 1.1, SP 1.2, SP 1.3, SP 1.4, SP 1.5, SP 1.6, SP 1.7 MA SP 1.2, SP 1.3, SP 1.4, SP 2.1, SP 2.2, SP 2.3 GP 2.7, GP 2.8, GP 2.9, GP 2.10, GP 3.2 REQM 1.5 VER VAL | 5.2 Project Plan Execution 5.4 Scope Verification 5.5 Scope Change Control 10.2 Information Distribution 12.5 Contract Administration 8.2 Quality Assurance 10.3 Performance Reporting |
Analyze project performance, risks, and issues, and take corrective action | PMC SP 2.1, SP 2.2, SP 2.3 MA SP 2.4 GP 2.7, GP 2.8, GP 2.9, GP 2.10 REQM 1.5 VER | 10.3 Performance Reporting 4.3 Integrated Change Control 7.4 Cost Control 8.3 Quality Control 6.5 Schedule Control 11.6 Risk Monitoring and Control |
Phase 4: Project Closure | ||
Complete project | 12.6 Contract Close-Out | |
Conduct project lessons learned | 10.4 Administrative Closure | |
Close project | ||
Terminate project funding instruments | 10.4 Administrative Closure | |
Archive project work products | GP 3.2 | 10.4 Administrative Closure |
Archive project measurements | MA SP 1.2, SP 1.3, SP 2.1, SP 2.3 GP 3.2 | 10.4 Administrative Closure |
Both CMMI and PMBOK have their respective strengths and shortcomings. The main differences are described in the following subsections.
Starting with the Project Planning (PP) process area, project management ala CMMI seems to be based on projects just mysteriously appearing out of thin air. CMMI does not say where projects come from or how they originate; presumably they simply exist and you can begin with planning. PMBOK does a much better job of addressing the origination of a project and how it can be initially scoped in such a way that the project begins as a proposal. If the proposal is funded , it can then be planned; if not, it (appropriately) dies.
Both CMMI and PMBOK do a good job of covering project planning activities and resulting work products. CMMI is more comprehensive in consciously addressing the selection of a life cycle and developing a project process that is a tailored version of the organization s standard process(es). PMBOK takes CMMI to school on risk management planning, but CMMI kicks PMBOK butt in planning engineering and support activities such as requirements development and management, validation, configuration management, and process quality assurance.
PMBOK beats CMMI in this area also. Although CMMI addresses planning system deliver and transition into the user or customer environment, it falls short of addressing the administrative closure of the project. In a purely CMMI world, a project never ends. (Hmmm, I wonder if that aspect of the model is really an abstraction of reality?) PMBOK makes sure that you close project accounting numbers or charge codes, that the customer has accepted the product/system, and that the project has collected lessons learned.
The concept doesn t even exist in PMBOK, so don t bother looking. CMMI s generic goals and practices are there to ensure that project management success can be repeated, irrespective of the players involved.
One of quickest ways to alienate software and systems developers and project leads is to come into their organization and start using the phrase formal standards as in we need formal standards to use in peer reviewing work products. Almost without exception, every software or system engineer I ve worked with completely tuned out the process people when they started using this S word.
The reason? Software and systems engineers today still view themselves and their craft more as artists and art and not an engineering discipline. (This self-image is misguided of course, but let s go along with it for now.) They view standards as something that inhibits or stifles the creative process of developing code. At this junction, you have really only two options: (1) align your efforts to institutionalize standards with the prevailing culture and beliefs or (2) prepare to fail.
To align your efforts to implement standards, first change your language. Instead of talking about standards, talk about the way we normally do things around here. Then, to spread those standards across the organization (i.e., institutionalize them), get people to take pride in knowing that they do a certain thing very well. Help them be proud enough to want to immortalize their expertise in the form of a document, so that others can benefit from the best way to do something. Viola! An organizational standard is born.
Prior to engaging in formal process improvement initiatives, many organizations have evolved over time a set of standards. Such standards may take many different forms including the formatting of various types of documents, the way people answer their telephones, work start time, what can or cannot be shown on a business card, how code is checked in and out of a configuration management system, what can be displayed (or not) in cubicles and offices. Such standards or standard practices may often exist simply as an aspect of the culture that has been around for a long time. They may not be documented anywhere , but nevertheless, people know about them and follow them.
Those same systems engineers who will tell you to your face that they don t need any stinking standards, will, if coaxed or approached in a nonthreatening way, quite proudly tell you that they ve developed the right way to do something over the years and that everyone in the organization should do it their way. Your instinct will be to dismiss it as arrogance , but you and your organization will be much better off if you recognize this for the goldmine it is ” you have powerful advocates of standards so long as you can avoid using that S word. These organic standards can serve you as a significant leverage point in your process improvement effort. Let s look at some examples.
Say your organization already has a default way status reports are formatted. By default I mean that if you were to look at a random sample of five to ten status reports, they would all have a similar look and feel, and contain similar content. Since these reports are the primary tools people use to communicate their progress and activities, this standard has saved you and the organization significant time and effort because you now don t have to figure out, or invent, how to write a status report.
Now you have to arrange to deliver some training. You ask around and find out that there s a particular administrative aid, Bill, who takes particular delight in making all the logistical arrangements for meetings and training events. He loves to secure the room and the equipment, arrange for food, and he ll even send out reminder e-mail to participants. This work isn t written down and it s not even a part of his documented job description, but he s really good at it and that s why everyone turns to him to do this stuff. Knowing this, why would you conceive of arranging your training logistics yourself? Why would you not delegate this work to Bill? And wouldn t you invite Bill, who is obviously a relevant stakeholder in matters concerning training, to participate in defining processes for the Organizational Training (OT) process area?
Remember the last time you were new to an organization, like when you last changed jobs? Remember how, in the first few weeks, people around you did things, but you couldn t discern why or how? It took you some time, maybe months or even years, to see the patterns in the way people in the organization worked. The same disorientation may occur when, after working in an organization for 20 years, someone new asks you why and how a particular task gets done. You have been working within the organizational norms (read: standards) and practices for so long that they have become part of your subconscious ” they are automatic. It is now difficult for you to consciously articulate to someone else who doesn t have the same experience.
Now here s the real leverage in existing organizational standards: as you observe people following standards (cultural norms, standards practices, recurring ways of doing things, etc.), write them down and start collecting them. It s natural to go into an organization with which you re not familiar and not see any visible (documented) standards and assume there are none. Do not make this assumption; it is almost always inaccurate. Quietly observe people doing things, ask questions, look for patterns of behavior, and then confirm the existence of a standard by asking several people. Write it down and get a few others to read it and give you feedback on whether or not you ve captured the standard correctly.
Here s an example of how to do this. You re planning to deliver an orientation on configuration management to people in your organization. You send out e-mail announcements to everyone in the organization. People show up and give you positive feedback. A week later, your boss comes to you, and has a conversation that goes something like this:
BOSS: Good job on that CM orientation; there was a good turn-out.
YOU: Thanks.
BOSS: By the way, why wasn t our marketing rep there?
YOU: Uh, well, I didn t send him a notice since he s not really part of our organization.
BOSS: Well, okay. But in the future, make sure you copy him on any CM matters. He always has approval on things having to do with product configuration.
Okay, you just learned a standard related to stakeholder buy-in on a certain aspect of your process improvement work. Write it down. Now, take it one step further. Go do some investigating and ask some questions. Find out who else within and without the organization normally participates in what activities/decisions and what exactly their participation is (eg., review, approval, input). The document that results from your investigation ” let s call it a Stakeholder Involvement Matrix ” will be of great value to you in two areas. First, it serves as a documented standard for identifying who participates in what and what their level of participation is. Second, it serves as a valuable tool in defining the intergroup relationships and dependencies, which will be integral to your organization implementing the Integrated Teaming (IT) process area and go a long way to establishing Generic Practice 2.7 ” stakeholder involvement.
Remember, organizational standards don t just one day fall from the sky. Standards come into existence when someone such as you takes the time and interest to document the subject matter expertise that is inherent in the organization and then gets people who are going to use the standards to agree that they represent the collective expertise and knowledge. Figure 1.4 illustrates the major steps involved in the evolution of a standard from its origin as an organic, assumed practice to a conscious, defined standard. These steps are described in detail following the illustration.
Talk to several people who frequently have to perform a similar task or develop a similar work product. A good example is project managers who frequently have to create a project plan for their projects. Gather multiple, variant examples of the work product from different projects. Document the similarities and differences. Talk to the project managers and get answers to questions on their usage of the project plans, such as:
What did you do differently and why?
What did you like about the project plan? What did you not like? What parts do you consider important? Which ones are not useful or don t add value to your job?
If you could have a template for doing the project plan in future projects, what would it look like? What would it contain?
Assimilate, analyze, and parse all the information you collect in Steps 1 and 2. Find the common best practices from all the instantiations of the work product and put them all into a pilot template. Also incorporate solutions from the answers to the questions asked in Step 2.
Remove any project-specific information (unless you identify it as example for instructional purposes), making the document generic for use in a wide variety of projects.
Get the project managers together and walk them through the project plan template. Tell them that you ve tried to compile the very best of the work they ve done in the past and that you ve tried to remove problems from the software development plan (SDP). Tell them that you need the new template to be tested out on some projects to see if it works. Get senior managers to publicly encourage people and provide them with incentives for testing new work products and providing feedback to the people managing its development and deployment. Test the new work product (SDP template in this case). Provide coaching and mentoring to project mangers on its use and collect their feedback on usage.
Incorporate the feedback into a new version of the work products. Collect any compliments or endorsements on the work product from the users.
Get approval, perhaps from the SEPG, to make the new work product available to all users in the organization. When you announce the new item, make sure you advertise that it represents known best practices and that it has been successfully tested.
If you work or have ever worked in an organization larger than 100 people, I can guarantee you that you don t have to start from scratch in developing and implementing a training program (OT). Even my small consulting firm has an informal (defined but not documented) process for planning, obtaining, tracking, and measuring training required by our employees . As with standards, organizational education and training programs and infrastructure often lie just below the visible surface of the organization and you may have to poke around to find the structures that have naturally evolved. The following subsections give you some clues for where to look. Don t forget to take your pen and notepad and write down what you find. Those notes will later become the organization s defined process (GP 3.1) for OT.
Even the smallest organizations usually allocate some number of hours per year to employees for training (OT SP 1.4 and GP 2.3). You ll even frequently find homegrown or off-the-shelf training databases used for planning and tracking training (OT SP 1.3 and SP 2.2). Then go look for the organization s preferred vender list (or ask someone who does purchasing if there s not a documented list), and you may find the names of vendors from whom the organization has acquired training. Figure out how they got on the preferred vendor list and you ll have information for OT SP 2.3.
Meetings are a tool and, depending on how the tool is used, can be a productive use of people s time and achieve measurable results or they can be a colossal waste of time and resources. Meetings are also the place where many decisions are made.
One of the many reasons meetings can be unproductive is because different people have different needs for attending meetings and therefore have different success criteria for meeting outcomes . These different needs can result in people meeting at cross-purposes and collectively not achieving anything as a team.
Here is a subset of some of the reasons people meet:
Make decisions
Assign tasks and action items
Get status on things; find out what s going on
Resolve issues
Plan work
Talk with other people
Be close to other people
Get a sense of belonging to a group
Exert influence on others
Entertain others
Be entertained by others
Argue or debate with others (as a form of entertainment)
Establish an alibi for not doing something else
So, if you hold or attend a meeting to make decisions and assign action items, but you re outnumbered by others with different purposes for the meeting, your success criteria has a good chance of not being met.
Productive meetings play a large role in implementing CMMI-based processes. Table 1.2 provides a short list of the typical types of meetings you can observe in almost any organization and CMMI practices that can correlate to the meetings depending on the content and agenda. Physical inputs and outputs associated with these meetings, such as agendas, minutes, and action items, can be used in an appraisal as direct and indirect evidence of the practices implementation.
Typical Meeting | Correlating CMMI Practices |
---|---|
Requirements JAD sessions or meetings with customers to clarify work requests or requirements | REQM SP 1.1, SP 1.2 RD SP 1.1, SP 1.2 RD GP 2.7 |
Project team meetings | PMC SP 1.6, SP 1.7, SP 2.1, SP 3.2 PMC GP 2.7, GP 2.8 |
Senior staff meetings | GP 2.10 for all PAs |
Project planning or work estimating meeting | PP SP 1.4, SP 2.2, SP 2.4, SP 2.6, SP 3.3 |
Meeting to review project plans | PP SP 3.1, SP 3.2, SP 3.3 PP GP 2.7, GP 2.8 |
Budget, resource or staffing meetings | PP SP 3.2 PMC SP GP 2.3 for all practices |
Project reviews | PMC SP 1.5, SP 1.6, SP 1.7, SP 3.1, SP 3.2, SP 3.3 GP 2.7 for all practices GP 2.8 for all practices GP 2.10 for all practices |
The paradox of meetings is that they have such great potential; they are the place and time where everything can happen. Yet they frequently don t live up to their potential and become the place and time where nothing happens. Your organization will inevitably conduct meetings related to CMMI or process improvement work, so you ll want to make meetings productive. And since it is likely that many of the decisions that affect the process improvement work will come from meetings ” such as SEPG meetings, steering committee meetings ” you need to make sure meetings become an environment where decisions can be made.
One of the more positive experiences I had with Xerox was its culture for meeting management, a piece of the company s LTQ program that won the company the Malcolm Baldrige Award in 1989. Xerox had meeting management down to a science long before the company ever began using CMM for process improvement.
Meeting management at Xerox consisted of a set of practices that over time became ingrained in the culture. These practices were designed to make meetings purposeful, useful, and efficient, as opposed to the complete waste they are in many organizations.
A close friend of mine experienced meeting management culture shock when she left Xerox to work for another company. Within a very short time after joining the new company, she became involved in a series of Joint Application Development (JAD) sessions to define and approve some system requirements. According to her, these JAD sessions were inefficient and people spent a great deal of time to achieve minimal results. The reasons: they couldn t stick to an agenda (if there was one), no one kept the discussions focused, and agreements were difficult to reach because there was no decision process such as consensus.
Many of us living in the corporate environment loathe meetings, primarily because we find them less than useless. Yet we have no choice but to accept that meetings are a way of life, and we must live with them. As part of Xerox s LTQ program, meetings were transformed from barely tolerable events to gatherings that were productive and useful.
How many times have you sat in a meeting in which the first 15 to 30 minutes were spent trying to remember the decisions and actions from the last meeting? Now multiply that wasted time by the hundreds or thousands of meetings conducted across the company every week. The waste of time and money really starts to add up.
Xerox made meetings productive by institutionalizing two cardinal rules for meetings:
An agenda for the meeting had to be published and distributed to participants in advance of the meeting.
Meeting minutes, particularly decisions and action items, had to be recorded, and then distributed to participants after the meeting.
The first rule ensured that people didn t just get together and then figure out what to discuss. It was wonderfully self-regulating because people felt safe to not attend a meeting if there was no agenda, regardless of rank or status of the person calling the meeting. The second rule ensured that what was decided or assigned wouldn t have to be remembered and possibly repeated in a future meeting; it guaranteed outputs and follow-up work.
With one client, we attended several meetings of the group responsible for planning, implementing, and governing CMMI-based process improvement. There were no meeting agendas, minutes, or action items because the client felt there was no payback on creating such documents. There also was no defined decision-making process. Not surprisingly, they would find themselves discussing the same topics and issues for weeks on end, meeting after meeting, with no definitive resolutions or conclusions.
So one of the first process improvement actions we helped them plan was called meeting management. You will not find a process area in CMMI called meeting management, but we knew we had to make meetings work before we could expect to achieve any other improvements.
We got them to try out some simple Word templates for documenting the meeting agendas and minutes. Table 1.3 shows an example of a meeting agenda at the top and then an example of the resulting meeting minutes below.
Systems Engineering Process Group Meeting Agenda for 6/16/03 | ||||
---|---|---|---|---|
Ref # | Topic | Leader | Type | Expected Results |
1 | Review minutes from last meeting and status action items | J. Abernathy | I, STA, D | Status and update action items as required. Expected Time: 15 minutes |
2 | Present and discuss as necessary NAVAIR Process Improvement Program Preread : NAVAIR SPI brief 20030604.ppt | Natural SPI | I | SEPG members to comprehend NAVAIR s overall CMMI process improvement policy, strategy, and structure Expected Time: 30 minutes |
3 | Review and concur to implement QA checklist for peer reviews Preread: QA Peer Review Checklist, V1 | L. Nguyen | D, A | Collect final comments/changes to checklist and obtain SEPG consensus to add to PAL baseline and implement. Expected Time: 10 minutes |
Agenda Types: I = Information sharing, D = Decision, A = Action, T = Training, STA = Progress/Status report, R = Risk, M = Measurements | ||||
Systems Engineering Process Group Meeting Minutes for 6/16/03 | ||||
Ref # | Topic | Leader | Type | Results |
1 | Review minutes from last meeting and status action items | J. Abernathy | I, STA, D | Status and update action items as required. See PEG action item log. |
2 | Present and discuss as necessary NAVAIR Process Improvement Program Preread : NAVAIR SPI brief 20030604.ppt | Natural SPI | I | Presentation resulted in discussion and questions. See action items 03-112 and 03-113. |
3 | Review and concur to implement QA checklist for peer reviews Preread: QA Peer Review Checklist, V1 | L. Nguyen | D, A | Checklist approved; Jeff to place in PAL and send out announcement. |
Agenda Types: I = Information sharing, D = Decision, A = Action, T = Training, STA = Progress/Status report, R = Risk, M = Measurements |
At the time of the meeting, the agenda is easily converted into the meeting minutes by simply changing the heading of the last column from Expected Results to Results.
To us (the consultants) it appeared to be simple and low effort to use these templates and, in fact, we knew this to be the case because we had used them in other organizations. But the client was still reluctant. So, we used a technique that has a high success rate, but which very few process consultants are willing to do: we, the consultants , rolled up our sleeves and did the work for them the first few times until they became addicted to the benefits. For several meetings, we produced the agendas and minutes. The client personnel quickly became accustomed to seeing and using these documents to structure their meetings. By the third instantiation, they had assigned a member of the group to take over the role of scribe to coordinate and publish the meeting agendas and to record and publish the minutes and action items. By the fifth meeting following the introduction of the templates, they were no longer rehashing old topics week after week and had gotten into a routine of efficiently processing issues. Meeting management had become institutionalized almost immediately.
Do all meetings need this level of structure? Of course not. There are types of meetings in which the only expected result is the free exchange of ideas, and there is no intention for their application, decisions, or for follow-up actions. But if you have a meeting from which you expect real results, not rambling; decisions, not dilly-dallying; and actions, not apathy; then put some structure around the meetings.
It s too bad that the CMMI Staged Representation has the Decision Analysis and Resolution (DAR) process area in Level 3, because it is one of those underappreciated PAs that would come in real handy right from the beginning of your organization s process improvement initiative. If I could go back and change one thing about how I ve implemented process improvement in organizations, it would be to implement processes based on DAR a top priority and get this one nailed down before taking on any other improvements.
Why? Because everything you will do ” from planning and conducting a baseline appraisal to developing a process improvement plan to executing that plan; everything ” will require decisions to be made. Every action, every result, every work product, every component of every process, every word spoken, every hurt feeling, every success and every failure will be the result of a decision (or a decision to not make a decision). Business is ” if nothing else ” about making decisions which in turn drive actions. Doesn t it make sense to put some structure and predictability around how decisions are made in your organization?
It would be easy to read the DAR process area and say, oh, we need to go build a decision process. Here s a news flash for you: people in your organization are already using their own processes to make decisions. These processes are most likely not documented and are likely executed at the subconscious level of thought. Still, you don t need to create a decision process; you need to go and explore people s minds and find out how they make their decisions and write it down. You need to ask questions before you start giving answers. Let s take another look at meetings and see what we can find in the way of decision-making processes.
People in organizations frequently made decisions but have no defined process, guidelines, or criteria for how decisions are made and every decision is made differently than the previous. This situation is the norm in most organizations.
Yet, with close observation (which requires you to suspend the belief that only you know the right way to do it ) you can see evolved decisions processes at work in meetings. Attend a few meetings and quietly take notes on observations such as:
What kinds of decisions are made or topics discussed in meetings? Which topics are never discussed in meetings but are topics which obviously require decisions to come from someone?
How many times did people look to a certain person to speak when a question came up about topic X?
Did everyone have a chance to speak on a certain topic? By topics or classes of topics, who spoke and who did not?
Who was in attendance when decisions were made? Which decisions were made without certain people in attendance?
Does it look like certain people influence the decisions or votes of others in the room on certain topics? Who is influential and in which topics?
Are decisions just assumed or does someone ever actually say something like, okay, so what we decided was ?
What kinds of decisions appear to be made but later are frequently reversed , ignored, or not understood ?
After a while, you ll see some patterns emerge. No one ever argues with Sara on requirements; what she says goes. Jeff solicits comments from people on budgetary matters, but makes a decision regardless of dissenting opinions . People generally don t accept the marketing manager s view on system design. The group won t make decisions when more than two members are missing. On the average, two out of five decisions need to be readdressed later. From these patterns, you can begin characterizing the decision-making process with generalizations such as:
Majority rule is the process for most decisions.
Decisions involving funding or money are made by N, with input from others but not influenced by others.
Changes to plans seem to require consensus.
Low-level implementation decisions are left up to the individual engineers.
Management commitments made to external individuals or organizations without prior discussion with the staff are usually ignored and not kept by the organization.
Once you have documented your characterizations (without naming names if possible), show them to the group you re trying to help. Let them know that you made observations that support the characterizations, how many observations, and on which dates. Try to get a general agreement from the group that your characterizations of their decision-making is close to accurate. If they agree it s accurate, find out which characterizations they feel good about and want to keep and which ones they don t like and want to change.
At this point, you have enough information to begin defining decision processes or guidelines for the group. You also have some baseline measures with which you can compare future measures (after
implementing changes) to see if things improved and by how much. You don t need to invent a decision methodology; there are plenty of them already documented in books and online. The four decision-making methods used most frequently in business are:
Autocratic: One person or position makes certain decisions alone. She or he may or may not consider input from others in the decisions.
Majority rule: The group or team members vote and the decision is carried by 51 percent or greater of the votes.
Consensus: All members of the group must agree to support the decision. Support doesn t necessarily mean everyone likes the decision; it just means they re okay with abiding by it.
Weighted voting: Weighted voting is best suited to decisions in which there are multiple or tiered choices such as prioritizing goals. Based on the number of items to rank or prioritize, each member of the group is given n number of votes and can distribute their votes among the choices based on rules. Weighted voting should not be used for situations or questions requiring a simple yes or no decision.
In the Tactical Air Range Integration Facility (TARIF; China Lake, CA), we used a variation of the approach previously described. After observing several meetings of their Systems Engineering Group (SEG) which is responsible for, among other things, organizational process improvement, we discovered that they had naturally evolved a form of consensus and had developed an intuitive sense of quorum. Based on these observations and characterizations, we were able to help them define a decision-making process for the SEG, which was documented in the SEG s Charter and Processes document. The process has since been modified slightly, but its basic tenets are still functioning.
Sometimes when I talk to people about measurements and measures, they act as if business, process, and product measures are something new, something introduced to the world by CMMI. Yet, once again, if you pop your head up out of CMMI and look around, you ll see that organizations have been finding ways to measure performance for quite some time. Think about it: What is a company s annual financial statement ” required by law for publicly-traded companies ” if it is not a collection of performance measures?
There are a number of sources of proven concepts and methods when it comes to process and product measures. The three sources I have found most useful in measurement work are Practical Software Measurement (PSM), [18] Goal-Question-Metric (GQM), [19] and Balanced Scorecard. [20] Balanced Scorecard, or just Scorecard, is one of the more robust and provably worthy schools of thought that has caught on in American business today. It is a collection of processes, methods, and sometimes tools that organizations use to collect, report, and analyze performance measures in multiple areas of business to determine the extent to which the organization is achieving its goals, implementing its strategy, or fulfilling the vision. Like implementation of CMMI-based processes, there are as many different manifestations of Balanced Scorecard as there are organizations using it. There is substantial literature devoted to all three of these sources of measurement knowledge, which won t be repeated here. What you will learn here is how CMMI, GQM, and Balanced Scorecard can all fit together to give your CMMI effort increased visibility and credibility by tying it to the organization s business success.
Here s a mantra for you to remember and repeat. The more you play this mantra in your head, the more you begin to see natural, simple beauty of the idea. It is a cyclical path that can help people in an organization ensure that what they re doing always has meaning, purpose, and direction.
Strategy and Vision beget Goals.
Goals beget Action Plans.
Action Plans beget Implementation.
Implementation yields Measures.
Measures indicate the accomplishment of Strategy and fulfillment of the Vision.
Here is something else you should realize: Balanced Scorecard gives organizations a way to communicate the strategy and goals and then measure performance against that strategy. CMMI gives you guidelines for establishing measurement programs (primarily through the MA, OPP, and CAR process areas), but also must start with the strategy from the top. GQM (and GQM-RX and GQM-Lite) is a tool for deriving measures based on the organization s goals which ” no surprise here ” come from the strategy.
So, if Balanced Scorecard starts with strategy and goals, and CMMIstyle measurements start with strategy and goals, and GQM starts with strategy and goals, where do you think might be an important place to start your thoughts and plans about measurements?
Do not start your CMMI-oriented measurement work by forming a process action team that will then spend months defining a measurement or metrics process which, in turn, will force people to collect all kinds of measures that are never used by anyone. Start by talking to the leadership in your organization to learn about the overall business strategies and goals. If you cannot find any business strategies or goals, or no one knows if they exist, you ve got much bigger problems than not having a measurement process.
But that s not a likely scenario; most businesses have something that can be called a strategy or things that can be called goals, even if people cannot articulate very well what they are. Search through documents for these words: charter, objectives, targets, annual, growth, performance, metric, quad chart, and Scorecard. Finding any of these words can lead you to finding the organization s strategy or goals. Talk to people. Ask them what they re currently measuring and reporting, how they re doing it and why, and to whom do they report which data. I haven t walked into an enterprise in America yet in which no one ever had to report any kind of measures or performance information. Again, don t throw away or ignore what is already in place; acknowledge it, understand it, and build on it.
Figure 1.5 depicts the relationship between three sources of measurement-related methods: Balanced Scorecard, CMMI, and GQM.
As you can see in the illustration, the highest level construct that simultaneously holds together and drives all goals, plans, and actions is the organizational or enterprise strategy. Organizations often divide the strategy into different perspectives such as Customer Focus; Finance, which includes things like ROI, ROA; Innovation; Operational Excellence; and Learning and Growth. Within the perspectives are goals which, in essence, are specific aspects of the strategy and their achievements can be verified through measures or indicators. Balanced Scorecard provides a method for driving and communicating the strategy down through all the hierarchies of the organization so that business goals, targets, and measures can be allocated to the most appropriate business units. A form of GQM is used to translate the organizational goals into action plans (see GQM Lite: A Quick-Start Approach for Process Improvement in Chapter 3 ” Managing the Process Improvement Project).
Action plans for improving quality, process, or productivity can be assigned to different implementation approaches or initiatives (e.g., CMMI, ISO, Six Sigma), and different business units (e.g., R&D, marketing, manufacturing). The execution of the action plans within the various implementation approaches or initiatives can and should yield measures which, in aggregate, indicate the extent to which the goals are being met and the strategy is being accomplished. Scorecard and, perhaps, the organization s MA and OPP processes are used to define the collection, analysis, use, and reporting of the measures from their lowest level of collection to the executives and senior managers who established the strategy.
CMMI-based process improvement vis- -vis the MA and OPP process areas is just one subgroup or category of process and product measures. Measures and indicators can and should also come from other implementation approaches or organizational units such as marketing, training, or human resources.
In JT3, JPEG made this concept real. Through much analysis, the group was able to establish and graphically depict the linkage between the lowest level process and product measures all the way up to the enterprise strategy. JPEG used GQM to derive the project level measures (53 in all) that would result from projects using the JT3 Enterprise Engineering Process (JEEP; a.k.a. OSSP ). All 53 base and derived measures are collected and used by the projects. The local Engineering Process Groups (EPGs) at the four test and training ranges (equivalent to business units) and the JPEG use the 53 project level measures to derive only a handful of indicators, which are reported upward as supporting the JT3 contract performance indicators. The contract performance indicators are then mapped to broad statements in the JT3 statement of objectives, which is the enterprise s strategy. The concept of this linkage is illustrated in Figure 1.6.
As depicted, the relationships between the measures in each stratum of measures, the indicators, and the organization s objectives and goals can be one to one, one to many, many to one, or many to many.
The power and benefits of a tool such as the one built by JT3 in Figure 1.6 are significant and include:
It clearly answered all the questions related to the collection, analysis, and reporting of measures: what gets collected, by whom, when, and how? Which measures get reported up the hierarchy and to whom and why and which measures do not get reported upward?
It gave the people involved in the process improvement work a strong sense of purpose and meaning for their work that had little to do with maturity levels.
It showed how the CMMI-based process improvement work will benefit the entire enterprise.
It gave everyone a tool for analysis. It became easy to determine the impact of not collecting certain low-level measures ” if we don t collect this, we cannot determine if Goal X is achieved.
[7] Goldratt, Eliyahu, Critical Chain, North River Press Publishing Corporation, April 1997.
[8] Johnson, S. and Blanchard, K., Who Moved My Cheese? Putnam Publishing Group, 1998.
[9] International Standard 9001, Version 2000-12-15 (ISO 9001:2000E), ISO 2000.
[10] Baldrige National Quality Program: go to http://www.quality.nist.gov/.
[11] Pande, P. et al ., The Six Sigma Way: How GE, Motorola, and Other Top Companies are Honing Their Performance , McGraw-Hill Trade, April 2000.
[12] Tingey, Michael O., Comparing ISO 9000, Malcolm Baldrige and the SEI CMM for Software , Prentice Hall, 1997.
[13] ISO to CMMI-SE/SW/IPPD, V1.1, SEI , Carnegie Mellon University, 2001.
[14] Rico, David F., Clause-By-Clause Comparison of ISO 9001:2000 and CMMI, 2002. Go to www.davidfrico.com for more information.
[15] Mutafelija, Boris, ISO 9001:2000 to CMMI Mapping, Hughes Network Systems, 2002.
[44] This information and subsequent information in this section is informed by a presentation developed and delivered by Dr. Rick Hefner and Leitha Purcell, both of Northrop Grumman Mission Systems. The presentation, Software Applications of Six Sigma, was delivered to the Los Angeles Software Process Improvement Network (SPIN) on January 29, 2003.
[16] The Project Management Body of Knowledge (PMBOK) is an online repository of project management information. This repository is maintained by the Project Management Institute (PMI). For more information, go to www.pmbok.com.
[17] West, M. and Byrnes, S., CMMI and PMBOK Synergy: Leveraging Process Platforms for Improvement, presentation delivered at the 2003 National Defense Industrial Association (NDIA) CMMI Technology Conference and Users Group, Denver, CO, November 2003.
[18] Practical Software and Systems Measurement is an organization devoted to developing, establishing, and communicating methods and tools for measuring software and systems work products and processes. For more information, go to www.psmsc.com.
[19] Basili, Victor R., Software Modeling and Measurement: The Goal/Question/Metric Paradigm, Technical Report, CS-TR-2956, Department of Computer Science, University of Maryland, College Park, MD 20742, September 1992.
[20] Kaplan, R. and Norton, D., Translating Strategy into Action: The Balanced Scorecard, Harvard Business School Press, 1996.