Contents:
The author provides concepts and techniques for CMMI-based process improvement which are as effective as they are innovative. Professionals at all levels from system engineers to CEOs will find a wealth of practical guidance and new ways to look at model-based process improvement that have already benefited large and small organizations in a variety of environments.
Using plain language and enlightening illustrations, the author identifies the most critical concepts of the CMMI, and explains how to turn those concepts into real process improvement. Table of Contents vii News Flash! Reviews "Michael West does a great service for many potential CMM or CMMI adopters by explaining the differences between pro forma and in-depth organizational process improvement.
We provide complimentary e-inspection copies of primary textbooks to instructors considering our books for course adoption. Request an e-inspection copy.
The Bookshelf application offers access: Offline Computer — Download Bookshelf software to your desktop so you can view your eBooks with or without Internet access. The country you have selected will result in the following: Product pricing will be adjusted to match the corresponding currency. Of course, if you are going to implement the CMMI, in whole or relevant parts to improve your capability, this book provides a clear roadmap for doing just that.
Do not let my previous remarks lead you to believe that this book is anti-CMMI because it's not. Regardless of your end goals, much of the material in this book applies to any activity, from strategic planning to process improvement to embracing a methodology. It's one of the best books I've read, and one that anyone contemplating CMMI should read before they read anything else about that model.
Then this book is for YOU! How many development cycles must one go through before you want to really change things re: The CMMI model is wonderful in that it offers a systematic approach to improve your SDLC that meets your specific needs and your product improves as your process matures. Besides the "easier said than done" hurdles you have or will encounter, the biggest challenge I have faced: Michael provides common sense approach to the common dilemma's and never ending battle grounds in software development and delivery phases: West leads you through no non-sense i.
I still find myself referencing the "What do you want to do Right Now" table! If you're in the software business and trying to decide on CMMI implementation, this book is a great resource and required reading for any process owner in your company.
Product Manager for a SaaS company. See all 6 reviews. Most recent customer reviews. Published on April 20, Amazon Giveaway allows you to run promotional giveaways in order to create buzz, reward your audience, and attract new followers and customers. Learn more about Amazon Giveaway. Set up a giveaway. Feedback If you need help or have a question for Customer Service, contact us.
Would you like to report poor quality or formatting in this book? Click here Would you like to report this content as inappropriate? Click here Do you believe that this item violates a copyright?
There's a problem loading this menu right now. Get fast, free shipping with Amazon Prime. Your recently viewed items and featured recommendations. View or edit your browsing history.
The phases in a process improvement project are very much like the phases in a software or systems development project. This section describes the minimum phases and tasks or activities therein for almost any CMMI-based process improvement project. Although the information herein is presented in a structure that appears to be a traditional waterfall life-cycle model, realize that there is plenty of opportunity for parallel and iterative work to be performed. There are at least eight distinct phases to a process improvement project, although your organization can decide to combine the work in two or more of these phases:.
Define and baseline the process improvement requirements Phase 3: Plan the process improvement project. Design and architecture of the process system and assets Phase 5: Build the process system and assets.
The following subsections briefly describe the critical tasks and activities for each of these phases. Your project s WBS will differ based on the project s goals, scope and applicability, and constraints levied on the project, such as a target date for achieving a maturity level.
Establishing the process improvement project is primarily a matter of defining the project s initial purpose goal , scope, applicability, and high-level success criteria. You will also want to at least get a start on defining the project s stakeholders. Before exiting Phase 1, you should negotiate and acquire at least enough resources and funding to execute project planning in Phase 2. The primary physical output of this phase is a document that defines the information described herein and an allocation of resources to execute project planning.
In Phase 2, the organization will define the requirements for process improvement. However, it will be very difficult to define reasonable process system requirements without some knowledge of the organization s current state in terms of process capability or CMMI maturity. Thus, a task to characterize or assess the organization s current processes and their implementation is frequently a large part of Phase 1. This sample WBS and those shown in the subsequent subsections intentionally do not include scheduling parameters such as start and finish dates and resources.
Remember, establishing the WBS is just the first step in establishing the schedule, which cannot be performed until you have more information developed and acquired in the next phase, project planning. Also, realize and accept the fact that much of what you initially define in this phase can and will change as you gather more information in subsequent phases. When the things defined in Phase 1 do change, it is the process improvement project s responsibility to communicate the changes with the stakeholders. As with other projects, the process system to be delivered by the process improvement or CMMI project should be driven by requirements.
The process system s requirements are derived from the project s goals, which define the desired state and the current state, which comprises the current process strengths and weaknesses and current business problems that might be resolved through process improvement. If the only requirement anyone can come up with for the process system is that it be used in an appraisal to achieve a CMMI maturity level, you probably don t have a strong enough business case for the project to proceed forward.
The primary output of this phase is a document that defines the baseline requirements for the process improvement project and the process system it will deliver. Again, the stakeholders as best you can identify them at this phase should have to review and approve the baseline requirements.
As with other projects, the requirements are likely to change in subsequent project phases, so it s a good idea to establish requirements traceability. For more information on defining and managing the process improvement project s requirements, read Getting from Measures to Process Improvement Actions: Managing Process Improvement Requirements in this chapter.
Establishing the project team read Establishing the Process Improvement Project Team in this chapter. Estimating cost, effort, and schedule for WBS tasks Defining task dependencies, constraints, and critical path or critical chain. The primary output of the planning phase is a process improvement project plan which either contains or references all related supporting plans or subplans.
Again, the process improvement project team will want to involve relevant stakeholders in the creation of this plan and its review and approval. You also need to define the process by which the process system and its components will be designed and built. The first task in process design is defining the terminology that you want people in the organization to use when talking about different process assets.
For example, when someone uses the word procedure, you want everyone in the organization to have a common understanding of what that term means. The next major task in this phase is defining the process by which the process assets will be developed. Will processes and assets be built from scratch or will legacy assets be incrementally improved? What will be the criteria for making such a decision? How and when will process assets be reviewed and what are the processes for accomplishing review and approval?
What is the process, method, or mechanism by which the various components of the process system will be integrated or linked together? Will process definition tools be used and, if so, how will they be used and what are the criteria for this decision? When answered , these and other similar questions will yield the process for process definition.
A large factor in designing a process system is first understanding the use cases: Process asset dictionary Process asset standards Process definition process description Process asset repository design and architecture. The fifth phase is to build the processes and assets in accordance with the design and architecture defined in the previous phase and in accordance with the project and process system requirements defined in Phase 2.
This is not a phase for people new to writing and technical documentation work. In the language of CMMI, we are verifying the system or validating it. There are a number of ways to verify that the process system or its components satisfy the requirements and other acceptance criteria such as standards. Peer reviews, walk-throughs , and inspection methods all work, so long as they are performed against objective criteria so that they don t simply become opinion polls.
A powerful lesson I ve learned in this phase is that, if you re not careful, you and the process focus or process development people can get caught in an almost perpetual loop of review and revision of the process assets. In the first and second reviews, people will catch about 80 percent of the defects. In the third review, they ll catch another 10 to 15 percent of the remaining defects. Now they re addicted to the quest for perfection and overengineering. People will spend 4 to 8 times the effort and money to remove the last 5 percent of defects as they did getting the first 95 percent.
This is a miserable return on effort and investment.
How do you prevent this? Up front in the planning, establish the exit criteria for verifying the process assets. In other words, get people to agree on a quantitative definition of good enough. In terms of validation i. This is where the process team gets tremendous payback on the usability and usefulness of the process assets they have built. The major word of caution here is: Don t ask people to pilot or validate process assets that are out of phase with the project s current phase or stage.
Don t ask project personnel to pilot your project plan template when it is already in system integration and test with the deliverables. In one single matrix, it provides both the piloting plan and the current status of process piloting efforts. This phase in the process improvement project would be called release or transition in a software or systems delivery project. Don t forget that the project needs skill sets that are different from the prior phases to accomplish this phase, primarily people with knowledge and experience in education, training, and knowledge transference.
There are two primary tasks or activities in this phase:. Determine the qualitative and quantitative measures which indicate the business results from the process improvement project. Announce, promote, advertise, and shout at the top of your lungs the business successes resulting from CMMI-based process improvement. Plan and conduct an appraisal to determine if the organization achieved a targeted maturity level or process capability from the process improvement project.
Have you read the previous sections on defining goals, requirements, and a WBS for your process improvement project? If not, what are you going to estimate? Before you can estimate the work involved in the project, don t you need to first know the tasks and activities by reading the previous section?
How do you respond?