Recently in Product Development Category
The primary cause of company failure is sometimes found in the company top.
Professor Per Nikolaj Bukh at Aalborg University, Denmark, has identified eight leadership tendencies that can kill your company.
The
common denominator behind the eight tendencies is that the entrepreneur who has built a successful
business thinks that he can handle everything himself, believing that
the success of the company is singularly attributable to his superiority in decision-making and
leadership.
This little guide, which is based directly on these eight tendencies, is so easy to follow that many company owners have already taken it to heart. Here is a tried-and-tested "how to ruin your business," no matter how great your products are or how competent your employees might be.
1. Decide Everything
Since you're the owner of your company that built your own business, it's you who can and should decide everything. You made the decisions when you created your company and made it what it is, and that means you should go on doing this. You may have hired subordinate managers since then, but don't let that keep you from making their decisions for them.
Make sure you become the bottleneck, and never mind the fact that although it's manageable to make all of the decisions in company with 15 employees, it's impossible with 200 employees. Also, don't pay attention to the fact that your subordinate managers become disgruntled and demotivated because their influence does not match their responsibilities.
2. Lose the Financial Overview
As your company grows, company finances become more difficult to control, and at some point a single person cannot manage the finances without an advanced business finance system that can provide an accurate picture of the financial status. Don't let that keep you from maintaining the financial records in your own head.
3. Go for Any Opportunity
The market is ripe with opportunities. Don't spend time stabilizing and consolidating your company with all these opportunities for making money. Let your development, customer promises, and deliverables slide while you you seek new avenues for profit.
4. Stay as Long as You Can
It's your company, right? If you must hand over your company to a successor, stay in your company and make the decisions as you always did, without mentoring your successor who won't get the required insight in the company to truly take over when the time comes.
5. Stick to Your Own Methods
You're a busy person, and you have lots of things to do. You won't have time to get out of your office and learn new techniques or get inspired by your staff. Using your known methods and sticking with your known tools beats skill building any time, even if it means your methods are outdated compared with those of your competitors.
6. Rely on Key Employees
If you delegate work, make sure you don't make the delegation role based. Your trusted employees must be named, few, and vital to your work so that you'll lose critical knowledge and skills if they are hired by other companies.
7. Make Wrong Investments
Your company is successful because you built it yourself. Don't outsource production tasks, and don't buy components from suppliers, but develop tools and components yourself.
Your best choice is to use your own investments for these developments, such as having your staff work on them. Firstly, such investments aren't clearly visible on your ledger, and secondly you know better than to trust academic business principles such as demanding a higher revenue from invested money than from borrowed money to justify the expenses.
8. Get the Bad Customers
The more customers the better, so focus on sales. Don't spend valuable time evaluating the customer's expected order placements or ability to pay, and don't spend time determining whether the customer matches the needs of your company. You need all the customers you can get, so don't reject customers that place too small or too large orders.
Professor Per Nikolaj Bukh at Aalborg University, Denmark, has identified eight leadership tendencies that can kill your company.
The
common denominator behind the eight tendencies is that the entrepreneur who has built a successful
business thinks that he can handle everything himself, believing that
the success of the company is singularly attributable to his superiority in decision-making and
leadership.This little guide, which is based directly on these eight tendencies, is so easy to follow that many company owners have already taken it to heart. Here is a tried-and-tested "how to ruin your business," no matter how great your products are or how competent your employees might be.
1. Decide Everything
Since you're the owner of your company that built your own business, it's you who can and should decide everything. You made the decisions when you created your company and made it what it is, and that means you should go on doing this. You may have hired subordinate managers since then, but don't let that keep you from making their decisions for them.
Make sure you become the bottleneck, and never mind the fact that although it's manageable to make all of the decisions in company with 15 employees, it's impossible with 200 employees. Also, don't pay attention to the fact that your subordinate managers become disgruntled and demotivated because their influence does not match their responsibilities.
2. Lose the Financial Overview
As your company grows, company finances become more difficult to control, and at some point a single person cannot manage the finances without an advanced business finance system that can provide an accurate picture of the financial status. Don't let that keep you from maintaining the financial records in your own head.
3. Go for Any Opportunity
The market is ripe with opportunities. Don't spend time stabilizing and consolidating your company with all these opportunities for making money. Let your development, customer promises, and deliverables slide while you you seek new avenues for profit.
4. Stay as Long as You Can
It's your company, right? If you must hand over your company to a successor, stay in your company and make the decisions as you always did, without mentoring your successor who won't get the required insight in the company to truly take over when the time comes.
5. Stick to Your Own Methods
You're a busy person, and you have lots of things to do. You won't have time to get out of your office and learn new techniques or get inspired by your staff. Using your known methods and sticking with your known tools beats skill building any time, even if it means your methods are outdated compared with those of your competitors.
6. Rely on Key Employees
If you delegate work, make sure you don't make the delegation role based. Your trusted employees must be named, few, and vital to your work so that you'll lose critical knowledge and skills if they are hired by other companies.
7. Make Wrong Investments
Your company is successful because you built it yourself. Don't outsource production tasks, and don't buy components from suppliers, but develop tools and components yourself.
Your best choice is to use your own investments for these developments, such as having your staff work on them. Firstly, such investments aren't clearly visible on your ledger, and secondly you know better than to trust academic business principles such as demanding a higher revenue from invested money than from borrowed money to justify the expenses.
8. Get the Bad Customers
The more customers the better, so focus on sales. Don't spend valuable time evaluating the customer's expected order placements or ability to pay, and don't spend time determining whether the customer matches the needs of your company. You need all the customers you can get, so don't reject customers that place too small or too large orders.
If you liked this post, share it with others:
Are you considering CMMI in your company, and are you new to CMMI? In that case this article may be just what you need to get started.
Somehow I think we need a "CMMI for Dummies," which appears to be one of the few "____ for Dummies" books yet to be written. But then again, real dummies probably wouldn't read books on neither CMMI nor any of the related fields such as process identification, process improvement, and enterprise architecture. You could of course sign up for SEI's Introduction to CMMI seminar and take the accompanying book, CMMI--Guidelines for Process Integration and Product Improvement, with you home, but in my opinion this wouldn't provide you with sufficient knowledge about CMMI. Don't get me wrong: SEI's introduction seminar and this CMMI book are both excellent and practically vital (the introduction seminar is in fact required for participation in the SCAMPI appraisal team that you'll assemble when your company is to be appraised for the next CMMI level), but they're certainly not enough. I'll refer to CMMI--Guidelines for Process Integration and Product Improvement as the "CMMI book" from now on.
I've worked with CMMI and process improvement for several years now, and I'd like to share some of my experiences and opinions with you. Keep in mind, however, that the following may not apply to your company. Good communication with your CMMI assessor is key to a successful appraisal. It is for the same reason I'm not going to cover the topic of the actual assessment, which your assessor can prepare you for much better than I can do here.
Capability and Maturity
CMMI is an acronym for "Capability Maturity Model Integrated." The last word basically means that CMMI is a fusion of best practices from a number of different capability maturity models that were eventually combined into a single model that is reminicent of the CMM.
So, CMMI is a capability maturity model. I think many of those who embark on the CMMI journey read the word "capability" and forget the word "maturity," and soon the company's CMMI sponsorship is directed towards specific IT systems or specific project lifecycles. This perspective is equivalent to viewing all problems as nails and then believing that maturity means buying a bigger hammer. I'm sorry to say it, but thinking you can "tool" yourself to maturity is the level of maturity of the young male that pimps his ride.
Maturity means that
whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and perform accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation.
Maturity does not refer to the use of specific tools or methods, but on how you work. For example, you can apply a project management method such as SCRUM both maturely, taking advantage of its potential to provide high visibility in terms of planning and status, its requirements management scheme, and its risk reduction advantages. But you can also apply SCRUM immaturely where the project manager neglects his or her responsibilities, operating at CMMI level 1 with a mostly unmanaged development group that relies on heroes for performance and sheer guesswork for planning. (Believing that a specific management model will make you mature is just another way of tooling yourself to maturity, since project management models and project lifecycles are just tools in your product development toolbox.)
This doesn't mean that capability does not matter, of course, and capability is closely connected with maturity. You'll need to solve your problems with proper tools, and if a different hammer is really needed, by all means go and get one. The use of proper tools is an indication of potential capability, but how you use the tools, and for what purpose, is an indication of your level of maturity: you hand out sharp knives to children only when they are mature enough to use them.
Remember, it's only a model, and as industrial statistician George Box once said, all models are wrong, but some are useful. It means that in the end, your company processes should be clearly recognizable as CMMI compliant, but they certainly don't have to look like the process areas that the CMMI describes. The CMMI "processes" are referred to as process areas, indicating that the "processes" described in the CMMI documentation are not really to be thought of as processes, but rather as containers for elements that should be found in the work processes of a company that meets the CMMI requirements. It is possible to grab the CMMI book and basically copy the process areas and make a one-to-one relationship between the CMMI process areas and your company processes. It is not necessary, however, and it probably makes much more sense to identify your company processes and then fit the elements of the CMMI process areas into your company processes. I'll get back to this later.
How fast does one mature on the CMMI scale? The SEI states that progressing from one maturity level to the next takes about 18 to 24 months from when a company starts with no processes and until it is ready for an assessment. The figure depends highly on your company, but if you have little experience with process improvement work, don't expect to be better than most others. One CEO who had been directly involved in the CMM (not CMMI) level 2 efforts in his company insisted that they had become CMM level 2 ISO certified within two calendar weeks, and hence progressing to CMMI level 2 or 3 would be a simple task for a company that capable. When we investigated the time sheets, we discovered that this figure was grossly understated: somewhere between 6,000 and 7,000 hours had been spent on the CMM level 2 preparations, and would have required everyone in the company to have put in 90 hours per week. It's good to be optimistic, but don't be delusional.
As you begin, you'll invariably be asked the question: "how much will it save us?" There's no way to answer that question up front, because in order to answer it, you would have to know how much the company is wasting on immature processes and work flows, and how much of that waste can be eliminated. As an expert enterprise architect once told me, just tell them "23%." It's a number that sounds appealing and not too sales-like, and the true figure your company can expect will be anyone's guess anyway.
Levels of Maturity
Search for CMMI on the web, and you'll find the five levels of CMMI:
Since all companies start at level 1, the CMMI model doesn't state any requirements below level 2. Level 2 is concerned with project planning and processes for managing projects, requirements, and suppliers, and introduces "support" processes that are vital for further maturity: configuration management, metrics and analysis, and quality assurance.
Level 3 introduces a large number of processes. Risk management is added to the project management toolbox, and the project management processes are expanded with processes for integrating separated teams in the management. This level also introduces three processes aimed at defining processes at company level rather than project level. Level 3 also involves processes for constructing products according to well-developed requirements, and for verifying and validating the products.
Level 4 adds processes for assessing objectively how the various processes perform, and for managing according to objective metrics and statistics.
Finally, level 5 provides processes for maintaining an organizational environment for innovation and for identifying and correcting the cause of problems and inefficiencies in the processes.
At each level, all of the processes for that level (and previous levels) must be institutionalized in the company. This means that the processes must become second nature to everyone involved in the processes, much like your morning ritual is probably second nature to you; it's a sequence of tasks that you perform and objects that you use without really thinking about it.
Institutionalization doesn't occur overnight. It takes a while for the employees in a company to get used to new processes to the extent where they believe this is what they've always done. Take note of this, because it means that progressing to the next CMMI level can easily take years.
I've avoided the discussion about continuous vs. staged representation until now. The two approaches aren't really that different, and I think they primarily indicate different company objectives with the CMMI. The staged representation organizes process requirements according to maturity while the continuous representation organizes process requirements according to capabilities. The continuous representation is a recommended order of introducing capability oriented CMMI practices (more on practices later) in order to also reach maturity. Since maturity and capability should go hand in hand, I think the difference is mostly a question of how the CMMI implementation is organized in the company.
Proprietary Language
One of the first things you should learn is the CMMI glossary. Many expressions and terms, e.g., "as appropriate," "establish and maintain," "adequate," "as needed," "consistently," "defined process," etc., may seem intuitively understandable, but have a very specific meaning in the CMMI context.
The CMMI book fortunately includes a glossary of the terms, but its descriptions are somewhat terse and in my opinion do not always clarify the terms.
For example, the explanation of "as appropriate" states that you should interpret CMMI goals and practices so that they work for your organization. This sounds easy enough, but it lends itself to another question: within what limits can I interpret the goals and practices? For such terms, it is a question of getting a proper feel for the needs of your company and making sure you do "not too little, and certainly not too much."
Striking a balance between "too little" and "too much" in terms of company needs versus processes is highly dependent on the nature of your company and I'm afraid also on the personal tastes of the various stakeholders. Too many process improvements projects have leaned towards the "too much" side, and as the one in charge of identifying and defining processes, it is easy to overdo the processes, making them too complicated for the target audience. It depends entirely on your company needs which metrics and which level of measurement granularity to use, what a particular CMMI practices means in your company (for example, SP 2.1, "Review Interface Descriptions for Completeness" in the product integration process area isn't quite the same to a software vendor as it is to a hardware vendor), etc.
For other terms it is easy to miss the point. For example, the term "establish and maintain" is so prone to misunderstanding it that the glossary actually states that the term connotes a meaning behind the words.
You'll find these terms throughout all the CMMI documentation, and if in doubt, always consult the CMMI book, and never assume you can figure out the meaning on your own. This is also true if you're ever in doubt or if you ever forget what some CMMI practice means: consult the book.
Policies, Processes, Procedures, Guidelines, Process Assets, and Tailoring
Much of the CMMI documentation discusses processes and makes little mention of procedures, perhaps in an attempt to avoid the rather frequent discussion of procedures in the CMM (the main predecessor of the CMMI) that had made the CMM appear unapplicably rigid. Procedures are nonetheless the primary building blocks of the CMMI, in my opinion. The reason I think so will probably become clear as I try to structure the various levels of process documentation involved in the CMMI:
At the top level, you have policies. At CMMI level 3, the company must have a policy for each CMMI process area stating in brief terms what major company goals each CMMI process area should meet. In my opinion, you don't have to phrase the policies in CMMI terms, organizing the policies according to CMMI process areas. You may instead want to have policies stating, say, that you must be able to fully recreate all of your shipped product versions, in case of the configuration management process area. Various CMMI appraisers will have different opinions on this.
Next, you have the processes (that is, your actual processes, not CMMI process areas). Each process involves a number of tasks to solve in order to meet certain goals, and it describes which work products are required to perform the process as well as which work products are produced by following the process. It also describes who performs the tasks. There's more to a process than this, but I'm mostly trying to explain where in the big picture you find the process. The process description is kept at a rather high abstraction level, describing what is done; you wouldn't, and shouldn't, know how to perform the process merely by reading the process description.
Procedures clarify the processes, explaining how to perform each step in the process. Your company will soon need several different procedures for the same process step, depending on department needs or project characteristics. For example, one of the CMMI process area steps requires you to estimate the effort required to develop your work products. It obviously depends on the type of work product how you estimate its size and the effort required to develop it, so you'll have different procedures and tools for that same process area step.
The procedures are kept practical. As a rule of thumb, someone that has received training in the tasks described by a procedure should be able to follow the procedure. If a procedure requires rather elaborate instructions, such as the use of a particular tool, you'd refer to instructions in the procedure. Procedures also refer to tools, templates, and guidelines. Guidelines are basically rules of thumb that are used to, e.g., describe considerations that one should make for particular decisions that don't lend themselves well to proceduralization.
Think of the detail level of processes, procedures, and instructions as a match to the skill levels of your colleagues:
At CMMI level 2, you basically make up the processes, procedures, etc. yourself. Together, they comprise a business manual for your project detailing how your project team should work on your project.
Then there's a huge conceptual leap to level 3, because when you're moving to this level you should be able to unify the processes across your projects so that they follow the same processes in the sense that what they're doing is the same. All projects conform (mostly) to the same processes, and the company provides a number of process assets that is the company's toolbox for following the processes. You no longer make up the processes or the procedures yourself, and so you don't have your own toolbox anymore. Instead, you specify which process assets you need for each process based on the process assets made available by your company. Your choice of process assets is your business manual. This choice of assets is referred to as tailoring of the process.
Modify your processes and procedures too much at level 3, and it basically means you're moving back to level 2 or level 1. I've heard department managers state that they're just interested in high-level processes, because they don't want to get bogged down by lengthy procedures. They'll just take the processes as inspiration and modify them according to their needs; as they said, "we'll tailor the processes so we can use them so they're completely lean and agile" (or whichever buzzwords the department manager is fond of that makes it sound like he or she keeps a well-trimmed budget).
That's a bad approach for several reasons.
Firstly, the processes are supposed to have been created based on the project and company needs, so they shouldn't need modification. If the department manager says he or she will want to modify the processes, then you probably didn't have the necessary buy-in from this rather important stakeholder when the processes were created.
Secondly, processes state only what to do, not how to do it. For example, "Estimate the size of the work products" might be a good process level description, but as any skilled programmer can tell you, estimation is no trivial task, and it can be performed in many different ways. If the process is to ever be put into practical use, you'll have to know how to follow the process; in the case of estimation, you'll have to know which estimation method and tools to use, among other things. When these department managers don't want procedures, then they don't want their employees to know how to follow the processes, which in turns means that they are basically saying that they don't intend to follow the processes.
Thirdly, tailoring does not mean you eliminate or modify parts of a process as you see fit. Tailoring means selecting those procedures, guidelines, templates, tools, and other process assets that are the best way to follow the process on your project. It does not mean omitting procedures or modifying procedures at will, because that's reverting to level 2 or level 1. Procedures describe how to follow a process, and tailoring means finding the procedures with the best fit for your project. Following the process is mandatory, and your freedom lies in determining how to follow the process within the limits of the tailoring guidelines provided by your company.
You certainly don't do what one project manager I've met thought he could do. He had discovered a specific agile project management style and believed this project management style would allow him to "tailor" the project planning process to omit all of the project plans, including configuration management plans, requirements management plans, risk management plans, verification and validation plans, and quality assurance plans. In short, he was expecting to be the tailor of "the emperor's new process," which was to be so lean you couldn't even see it.
Beware also of the entrepreneurs. They are often highly motivated, but are also highly prone to ignoring processes and procedures, and want to focus on tools and tend to manage "their way," which in practice means a crude level 1 way. They can be problematic both when you identify and describe your processes, and when eventually you deploy the processes throughout your company.
I'm not very willing to accept arguments stating that you're a company with rather different types of projects, so you can't use the same processes in one department as in another. Yes, you'll have different ways of doing things in your projects. Most likely many of your procedures are going to be different. The processes are going to be mostly the same, however, and unless you want to fail the assessment, the CMMI process areas must be identifiable in your processes. Remember that probably much bigger companies than yours with highly complex products are able to follow the same processes throughout the respective companies, so if you think your company can't, then probably you don't have sufficient insight into either your own company, your processes, or the CMMI process areas.
There are times when a practice may be very significantly reduced in scope or in rare cases ignored. It seems reasonable that small companies will have processes and procedures that are relatively simple while large corporations will have a huge array of different procedures for following the processes.
You can't leave any process areas out, except the supplier agreement management process area in case you don't integrate components provided by other suppliers into your products.
Goals and Practices
Each CMMI process area aims to meet a few goals. These goals are mandatory: your company must demonstrate that those goals are met, or you will not be compliant with the process area.
The CMMI process area goals are met by following a number of specific practices (SP) and generic practices (GP). These practices are "recommended," which for all practical purposes means mandatory. It means you can omit a practice, but you had better have a very good reason for doing so, and you should describe what you're doing instead that's just as good. Finally, there are optional practices. I prefer to think of them as suggestions to what you might do, and they serve well as clarifications of the recommended practices.
Specific practices are relevant only for the particular process area. For example, SP 1.3, "Establish Verification Procedures and Criteria," of the verification process area, is obviously relevant for verification only.
Generic practices are practices that are essentially the same regardless of process area. For example, GP 2.8, "Monitor and Control the Process," states that the progress and performance of each process area should me monitored, and that corrective action should be taken if irregularities are detected. This is true for any process area, no matter if it's verification, configuration management, or project planning. You should, in fact, make sure that all of your processes are monitored and controlled this way, not just the process elements containing the CMMI process area elements.
Be careful with the generic practices. They are the same for all of the CMMI processes areas, and it's easy to think this means you have a small total of ten generic practices to follow (at CMMI level 2). That's an understatement, because you have seven process areas at level 2, and each of the ten generic practices applies to each process area. It's not true to say this yields 70 practices, though. For example, GP 2.5, "Train People," means that your company should train to people to follow the appropriate procedures, and while certainly proper training applies to all processes, you probably wouldn't add a training task in each process; instead, you would probably have some sections in some processes taking care that your employees receive the needed training.
Several of the generic practices will seem redundant or self-referencing. For example, GP 2.2, "Establish and maintain the plan for performing the process," means that each step in your process should be planned so you know how long it takes, when it is to be performed, and which resources it requires. This seems redundant for the project planning process area, because the project planning process area is concerned with just that: planning. But in fact the project planning process itself should also be planned; for example, part of the project planning process area includes estimation of the size of the work products to be developed. Estimation is not a trivial task, however, and may involve specific people whose time must be allocated. You therefore need to plan the estimation, and when you've planned the various tasks involved in the process planning process area, then you'll know the effort required by the initial planning phase of the project. You'll find similar apparent redundancies for project monitoring and control, configuration management, etc.
Document Your Existing Processes First
It is tempting to grab the CMMI book and apply the process areas as they are, that is, as if they were processes, to your company at the level of detail matching the requirements of your organization. This isn't entirely wrong, of course, and you can (mostly) follow each process linearly in a waterfall-like fashion. For example, the project planning CMMI process area involves a set of specific tasks that you'll most likely want to perform, and probably also roughly in the same order as the practices are described in the CMMI process area. I suspect it is the waterfall-like form of the CMMI process areas that have led to the myth that CMMI cannot be combined with various lean practices.
I think there's a better approach, though, and I'll assume you're starting from scratch.
First of all, you need a group of people responsible for describing the company processes. This group must be assigned one hundred percent to this task, because otherwise they will soon find themselves working on other projects, neglecting the process work. In addition, the group must have full sponsorship from the company, which means time and resources must be allocated for the group. Nothing weights less than a promise.
I cannot stress the importance of sponsorship enough. There must be time and budget plans for the process improvement work and according allocation of resources. It is not possible to perform process improvement by assigning process improvement efforts as secondary tasks that are to be solved when occasionally there is a little spare time in the company during low-stress periods.
If your management won't allocate the necessary resources to your CMMI process improvement efforts, forget you even tried. Try to find out why your sponsor wants the CMMI. If your sponsor wants to improve your company's performance and maturity, then maybe your sponsor understands the importance and value of CMMI. But if your sponsor's primary goal is to receive a CMMI level 3 (or whatever) assessment for sales purposes, then probably you don't really have the sponsorship needed for your efforts. I think your sponsor should not only tell you about their commitment but also their customers and the general public. If they're willing to do that, then they'll have something at stake that may keep them motivated.
It does cost money to define, deploy, and institutionalize processes--both in terms of salaries, appraisal expenses, and opportunity cost, that is, the opportunities missed because key personnel was working on processes--but the payback should be obvious: reduced overhead, reduced defect rates, re-use, and better planning are just some of the benefits of well-defined processes. Think of it as an investment similar to education: if you think education is expensive, try stupidity.
Secondly, make contact to a CMMI appraiser who will perform the CMMI appraisal of your company. There are several advantages to getting in touch with him or her early. Firstly, the appraiser can help you interpret the CMMI, which can appear somewhat cryptic at times. Secondly, the appraiser can help you ensure that your processes meet the CMMI requirements so you won't discover until the time of the appraisal when process changes are going to be expensive compared to getting it right the first time. Lastly, and perhaps most importantly, your appraiser will be familiar with your company processes, company needs, and your internal stakeholders, and will spend less time understanding your business and processes and learning to communicate efficiently with your colleagues.
The group should familiarize itself carefully with all of the CMMI goals and practices, including the optional practices that may not apply to your company. Make sure you understand what they all mean. You may think terms such as "GP 2.8, Monitor and Control the Process" for some process sound evident or easy to follow at the time you read the books, but did it occur to you that this could imply that project managers must track their progress in the process and take appropriate action if they're deviating from the planned progress, and that this tracking task must be added to the company processes? Similarly, "SP 1.2, Establish Estimates of Work Product and Task Attributes" may sound reasonably easy and intuitive, but do you know what is meant by work product and task attributes? And does "attributes" refer to both work products and tasks, or does it refer to just the tasks? Margaret Kulpa's and Kent Johnson's book, Interpreting the CMMI, provides an excellent walk-through of the various processes, and I recommend you buy it.
Once the process group understands in detail what all of the CMMI practices entail, forget about the CMMI processes for a little while. You're supposed to create processes that help your company, not to create a company that follows specific processes.
If your company is at a low level of maturity, don't expect that your colleagues will to be too happy with the prospect of procedures. Your successful implementation of processes and procedures depends on stakeholder buy-in. If a procedure involves a number of people, all of them must be able to see that the procedure is working to their advantage. They must understand why the procedure helps them directly or indirectly. If they feel the procedure is working against them or that the procedure is useless compared to whatever they happen to do instead, that is, if you put on the "the procedures aren't here to help you; you're here to follow the procedures" attitude, then they won't follow the procedure. The combination of will, violence, and vaseline may be required in some cases, but try to do this as little as you can.
Fortunately, you have somewhere to start. Recall that at level 1, your company is performing. You don't know exactly why or how, but something is evidently right somewhere. You probably have skilled colleagues working together, and somewhere in the team there has to be agreements and negotiations that lead to a product in the end. There's something behind their noisy work behavior that can be worked with, and that's your processes. Your task is to identify them and describe them.
In addition, you know which processes you should focus on, namely the ones that correspond to the CMMI level you're aiming for. If you're aiming for CMMI level 2, you should focus on managerial processes and "support" processes and try not to get too technical with the people that are constructing the products, because that's reserved for level 3.
The development of the process descriptions is possibly the second-most difficult task you'll face as responsible for CMMI in your company. It is largely a question of dealing with people, and it is a situation where everyone has an opinion that must not just be heard--it must be satisfied. Dealing with people can be a challenge in engineering environments. Books such as Kathleen Reardon's The Skilled Negotiator or Rick Brinkman's and Rick Kirschner's Dealing with People You Can't Stand may be helpful. (I'm not implying that engineers are people you can't stand, but they can be an opinionated bunch of people who will rather become grumpy afterwards than tell you what they think in terms of processes and procedures, and you'll have to deal with that.)
Alec Sharp's and Patrick McDermott's book, Workflow Modeling, is a very practical approach to process modeling. The other books I've read on process modeling have focused on how to describe the models in precise terms such as using UML diagrams, but I feel this is one of the less important aspects of process modeling when it comes to modeling the processes of how people work. Your focus should stay on making people understand the processes, not on the exactness of the format of the process description. Put a little bluntly, you model your company's processes because you want to communicate with the people performing the work, not because you want an accurate model useful for programming an army of robots.
Your colleagues know something, but they're not sure what it is, or how to say it. You don't know it, but with Workflow Modeling you'll have a significant number of skills and tools to find out exactly what your colleagues are doing as they develop the products.
Develop the process descriptions in enough detail so that your colleagues know what to do (the process), and to a reasonable extent how to do it (the procedures). You'll have to go all the way down to procedures in many cases, because otherwise you're going to miss some of those people that are involved in the process and must be satisfied. It won't be lost effort, because eventually you'll have described these procedures and put them to use anyway. (You know you've gone too far when you're writing "From the Tools menu, select Preferences ... .")
You don't want to consider specific instructions, guidelines, checklists, and templates at this stage, but you'll probably want to know the major features of the tools used. Just keep in mind that your current process is the one that you're about to improve, so don't get lost in details that are bound to change.
Make sure the process descriptions explain what your company is doing right now--this is the so-called "As-Is" process. If you're expected to measure whether applying CMMI to your company will optimize various key metrics, this is also a good time to introduce metrics in the As-Is processes provided your company is mature enough to gather such metrics. These metrics can be compared with the metrics after the processes have been improved, and you'll be able to see the result of the change in terms of these metrics.
You may want to get familiar with Enterprise Architecture, which is an excellent framework for modeling both business strategy, informations systems, processes, change management, and knowledge management. I haven't been able to locate any "perfect" book on Enterprise Architecture, but I suggest An Introduction to Enterprise Architecture by Scott A. Bernard.
After Documenting the As-Is Processes, Apply CMMI
Eventually you'll have documented your existing company processes, and the next step is relatively easy. Since you're familiar with the CMMI requirements at this point it should be fairly evident to you where the existing processes do not live up to the CMMI requirements. Workflow Modeling includes guidelines on how to improve existing processes, only do you not have to be particularly creative and innovative, because the CMMI model already states what's required, and the company policy for each CMMI process states which goals each process must meet.
But remember: no matter what you add to, or change in, the existing processes, all of the people affected must think it's a good idea.
It's easy to forget the company policies for CMMI processes, so remember to ask yourself the question: "does this new process description meet the goal that (insert policy for the appropriate process)?" If the process does not meet the company goal, the resulting procedures will cause the employees to work on something that deviates from the company goals, and you don't want that to happen.
Don't worry too much about "getting it right" the first time. You should avoid obvious errors and non-compliance with the CMMI practices, of course, but don't gold-plate the processes. Remember that no matter what you do, it will always be possible to improve the processes (after all, that's what level 5 is all about), and you can always fix minor issues or clarify procedures and instructions during what will hopefully be your periodical process adjustments. At some point, good enough is good enough, and going into too much detail may deviate too much from your current processes, making it cumbersome to deploy the process changes in the company. Change hurts, so don't change too much at a time lest your colleagues be writhing in regulative pains.
You may find that in many cases you can't describe the necessary procedures; for example, the CMMI book doesn't describe in detail how to estimate the size of a work product. This is where your colleagues must apply their professional skills, and where you may have to consult experts on a variety of methods. For example, the requirements development area may lead you to study use cases, joint application development, etc., which may require skills that you do not have in your organization. For software development companies, consider Steve McConnell's book, Rapid Development, your bible--it is a tutorial on most of what you'll need on the various development practices.
Various surveys indicate that the configuration management process area appears to be a rather neglected set of practices in many companies. Configuration management is also a generic practice for all processes. Be careful not to think that revision control using tools such as CVS, Subversion, SourceSafe, etc. will suffice. Revision control is vital for configuration management, but configuration management also involves lifecycles for changes and strict use of change control. Chances are that the configuration management process area is a good place to start in your company.
When you're about to move to level 3, I suggest you start with the CMMI processes areas named "Organizational Process Definition" and "Organizational Process Focus." These processes areas describe how your company will define your processes for use across the company, and how you'll maintain your processes, respectively.
This looks like a chicken-or-the-egg situation, because you're going to define your process by following the very process you're about to define. In practice it's not that bad. You're starting from scratch, and that means anything you do is your best bet on a process at the moment, so you have your egg right there. You probably can't find a proper place in the company processes for all of the organizational process definition and organizational process focus practices to begin with, but no-one says you must finish one process area completely before moving to another process area, so don't consider this a problem. Also, the other CMMI process areas can help you define the processes. If you think of your process definitions as work products that you're going to release, then identifying and writing the processes are related to the requirements development and technical solution process areas, and planning and maintaining the work are related to the process planning and process monitoring and control process areas. Deployment of the processes (more on that later) can be thought of as integration and configuration management process area tasks.
Next, work on the organizational training process area. This is the process area that will be used to train people throughout the company in your new processes and procedures, and at CMMI level 3 your colleagues will need lots of training owing to the large number of processes areas introduced at level 3. If you need other people to work on the process definition and process focus areas, you may consider working on the organizational training process before you even begin on the process definition and process focus processes. This is reasonably safe, because there is probably not going to be much variation across projects in terms of how organizational training works. (The organizational traning process area focuses on the organization's role in training, not on project specific training.)
Once the organizational process definition, organizational process focus, and organizational training process areas are reasonably finished--that is, when those that are responsible for the company processes meeting the requirements of these process areas know how to follow them--start on the remaining processes.
In my opinion, it is very important to work generic practices 2.8 and 2.9 into the processes as early as possible. GP 2.8 means you monitor how well the process itself performs; e.g., how much effort is spent on implementation versus effort planned, and taking corrective action when significant deviations are detected. GP 2.9 means you (or others) monitor how well you stick to the process and take corrective action if necessary. If you define good metrics for these generic practices (and that implies you'll have to work hard on the metrics and analysis process area as well), not only will it be readily apparent how well the processes are performing, it will also be your sponsor's tool for keeping focus on the processes, with help of generic practice 2.10, which states that upper management must be kept aware of the process performance.
Artifacts
A CMMI level assessment involves an inspection of your company's processes, most likely according to the so-called SCAMPI method. The goal is to determine whether the CMMI practices are described in your company's processes, and whether your company follows these processes. The former is easy enough, because that's basically your business manual. The latter is a little more involved, because your CMMI assessor will have to search for tangible evidence--the so-called artifacts.
An artifact in the CMMI context is something that proves that a particular CMMI practice has somehow been followed. For example, an issues list with action items assembled from a peer review of a document is (probably) evidence that SP 2.2, "Conduct Peer Reviews," of the verification process area has been followed.
For each CMMI practice, at least one direct artifact and at least one indirect artifact must be identified. Apparently many people are confused by the terms "direct" artifacts and "indirect" artifacts in the SCAMPI method. The distinction is somewhat unclear at times, but as a general rule, a direct artifact is a work product that is a directly desired output of a particular practice, and an indirect artifact is a work product that doesn't really have any value by itself, but which could only have been created as a byproduct of performing that particular practice.
For example, the call for review or the reviewers' time registrations indicating time spent on a review might quality as indirect artifacts, because the existence of such evidence wouldn't make sense unless the peer review practice had been followed. Hence, an indirect artifact can be a work product that was necessary to produce the direct artifact and useless for other purposes, an activity that wouldn't have made sense unless the practice was followed, or some secondary work product that would only appear if the procedure was followed.
CMMI SCAMPI Distilled by Dennis M. Ahern, Jim Armstrong, Aaron Clouse, Jack R. Ferguson, Will Hayes, and Kenneth E. Nidiffer explains the SCAMPI appraisal method and includes a long appendix with a list of example artifacts for each CMMI practice.
Deployment
Deployment means that your new processes are put to use in your company.
It is reasonably easy to deploy new processes and procedures in individual, independent projects, as is the case at CMMI level 2: you just state which processes and procedures are to be followed, and that's that. If this means you'll have to update work products from an earlier phase of the project, then these updates must be planned, of course.
It is much more complicated at level 3 where the same processes and procedures must be deployed throughout the company. The organizational process focus area requires you to plan the deployment, and there are several issues to be considered. Modeling the company according to an Enterprise Architecture framework pays off here.
If you expect most of your current projects to finish within a foreseeable future, maybe your deployment can simply state that: "All new project follow business manual version 2.1," but don't expect to be this lucky.
Most companies will have several active projects in different stages of completion. Some projects may not be expected to finish until years into the future. It is not necessarily desirable to rework all of the project's work products to comply with the new procedures, and you may even be contractually obliged to stick to a particular set of procedures. How does one deploy process changes to active projects that are following known procedures?
There's no simple answer to that question. You can probably deploy some process changes in some of your active projects, and although this will almost certainly help institutionalize the new processes, these projects won't otherwise help in your CMMI assessment, as the projects are not compliant with the next-level CMMI processes until all of the CMMI process areas for that level are found in the projects.
In a sense, it is all a question of configuration management and requirements management at project portfolio level where you'll have to evaluate the effect of the process changes on each project and maybe determine how a project should "branch" (in the language of configuration management) and subsequently "merge" at a later stage. Think of it as if you're maintaining different versions of your business manual at the same time.
Before you roll out changes throughout your company, conduct pilot runs. Try a new procedure on a guinea pig project where the risk of failure will not have significant impact, collect feedback on the effectiveness of the procedure, and then determine whether it should be changed before it is deployed throughout the company. Another pilot run may be necessary.
Monitor and help the test subjects carefully as they try to follow the new procedures. I find it advantageous to organize procedures meant for pilot runs as "checklists" where possible, in the sense that it should be possible to understand when some step in the procedure causes problems or should be changed or omitted, and in all cases why.
Also, remember that the project must receive sponsorship as the procedures can be expected to require some initial effort on the project. Time and resources for the pilot runs must be planned and allocated.
Sponsorship is also required on the actual deployment after the pilot run has completed successfully. The deployment will fail unless you obtain sponsorship for the effort required to deploy the processes.
Your sponsor may have found it acceptable to spend resources on the definition of processes, but the prospect of decreased productivity in the various departments while new processes are adopted may cause the sponsor to withdraw the funds allocated. Prepare your sponsor in the very beginning of the CMMI efforts that this will happen.
Sponsorship must also exist at the lower levels of management. The department managers are probably expected to maximize their earnings, and as long as their success is measured by that metric, then they won't spend effort elsewhere. A different metric must be introduced for the department managers' success: a metric indicating process compliance, and it must be more important to their sponsor than the earnings metric. This is one of the reasons why I stressed the importance of being able to monitor the processes in the discussion of the To-Be processes.
If the department manager truly wants process improvement and is willing to allocate the required resources, the department manager will also want to monitor the process compliance of his or her subordinate managers, who in turn will be motivated to monitor the process compliance of their teams.
Start early with the supplier management process if you want your level 2 assessment as soon as possible. This process may not be your most important process, but remember that the CMMI assessment requires you to demonstrate artifacts collected for several projects. This can be difficult if you have only a limited set of suppliers, or if only few projects make use of suppliers. Starting early with the supplier management process may help you gather enough artifacts for the assessment.
Institutionalization of the To-Be Processes
Institutionalization means that the processes should become second nature to all of the involved stakeholders. They must feel that this is how they've always done things in your company.
Institutionalization begins at the moment a process is deployed, because people will now begin using--and hence getting used to--the process. Successful institutionalization requires a bit more, however.
I believe institutionalization is the hardest part of the CMMI process improvement, primarily because it requires sponsorship over a long time with little sign of returns of the investment. You'll also have to convince your sponsor that his or her employees must receive training, and projects will have to change their plans according to the deployment plans. Again, the first keyword is sponsorship.
The second keyword is training. For each new procedure, the appropriate people must receive appropriate training. Note my use of "appropriate." It depends on both the role played by the various stakeholders, their levels of experience and expertise, and the nature of the procedure. For example, if a new peer review procedure is deployed, training may be a simple walk-through of the procedure, followed by reminders of the major steps in the procedure the first several times the procedure is used. If a new requirements development procedure calls for the use of use cases, perhaps the estimators must take classes to learn how to effectively apply use cases. (By the way, I highly recommend Use Case Modeling by Kurt Bittner and Ian Spence for that.)
In all cases, I think the relevant stakeholders should receive a class introducing the company processes, explaining why the processes are formed the way they are and which benefits they introduce. Make sure that each person understands why he or she is better off with the new processes. This can be a challenge in the early stages of maturity where your colleagues may not appreciate that the result of bureaucracy or an apparent inefficiency in one area is desirable if it increases overall efficiency. Part of the institutionalization at an early stage of maturity is a change in company values from hero worship to valuing compliance to processes. It is tempting to be happy with one man's superior performance, but an average team that works according to efficient processes is much more productive than a disorganized team with one hero. Such a change may be easier in some cultures than others. Expectations from the sponsor will trickle down through the company, so make sure the sponsor himself or herself desires this change of values.
Many procedures require specific skills, such as procedures for estimating, implementing the technical solution, planning, developing requirements, analyzing metrics, delivering training, etc., and many tools require training as well.
You don't necessarily have to organize all training as classes, of course, and you may instead find it advantageous to employ several training methods, including mentoring, workshops, e-learning, etc. I have found it very effective to briefly reiterate a procedure before it is put to use; for example, if a formal peer review procedure is followed, you might want to remind the reviewers of their tasks and remind them to consult to the procedure. Eventually they'll do it on their own.
But never expect people to "just know" how to follow the processes, or even to follow them at all, just because you tell them to. Putting a procedure to use isn't training but experience, just like one gets used to a tool.
Over time, hopefully everyone will become used to the processes to such a degree that the processes will not begin to fade or deteriorate as soon as management forgets to remind the employees of the importance of the processes. This is when you're ready for a CMMI assessment. Your assessor should be able to help you determine when you're ready.
Note: the author of this article is not affiliated with the SEI. Opinions expressed in this document are those of the author.
Somehow I think we need a "CMMI for Dummies," which appears to be one of the few "____ for Dummies" books yet to be written. But then again, real dummies probably wouldn't read books on neither CMMI nor any of the related fields such as process identification, process improvement, and enterprise architecture. You could of course sign up for SEI's Introduction to CMMI seminar and take the accompanying book, CMMI--Guidelines for Process Integration and Product Improvement, with you home, but in my opinion this wouldn't provide you with sufficient knowledge about CMMI. Don't get me wrong: SEI's introduction seminar and this CMMI book are both excellent and practically vital (the introduction seminar is in fact required for participation in the SCAMPI appraisal team that you'll assemble when your company is to be appraised for the next CMMI level), but they're certainly not enough. I'll refer to CMMI--Guidelines for Process Integration and Product Improvement as the "CMMI book" from now on.
I've worked with CMMI and process improvement for several years now, and I'd like to share some of my experiences and opinions with you. Keep in mind, however, that the following may not apply to your company. Good communication with your CMMI assessor is key to a successful appraisal. It is for the same reason I'm not going to cover the topic of the actual assessment, which your assessor can prepare you for much better than I can do here.
Capability and Maturity
CMMI is an acronym for "Capability Maturity Model Integrated." The last word basically means that CMMI is a fusion of best practices from a number of different capability maturity models that were eventually combined into a single model that is reminicent of the CMM.
So, CMMI is a capability maturity model. I think many of those who embark on the CMMI journey read the word "capability" and forget the word "maturity," and soon the company's CMMI sponsorship is directed towards specific IT systems or specific project lifecycles. This perspective is equivalent to viewing all problems as nails and then believing that maturity means buying a bigger hammer. I'm sorry to say it, but thinking you can "tool" yourself to maturity is the level of maturity of the young male that pimps his ride.
Maturity means that
whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and perform accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation.Maturity does not refer to the use of specific tools or methods, but on how you work. For example, you can apply a project management method such as SCRUM both maturely, taking advantage of its potential to provide high visibility in terms of planning and status, its requirements management scheme, and its risk reduction advantages. But you can also apply SCRUM immaturely where the project manager neglects his or her responsibilities, operating at CMMI level 1 with a mostly unmanaged development group that relies on heroes for performance and sheer guesswork for planning. (Believing that a specific management model will make you mature is just another way of tooling yourself to maturity, since project management models and project lifecycles are just tools in your product development toolbox.)
This doesn't mean that capability does not matter, of course, and capability is closely connected with maturity. You'll need to solve your problems with proper tools, and if a different hammer is really needed, by all means go and get one. The use of proper tools is an indication of potential capability, but how you use the tools, and for what purpose, is an indication of your level of maturity: you hand out sharp knives to children only when they are mature enough to use them.
Remember, it's only a model, and as industrial statistician George Box once said, all models are wrong, but some are useful. It means that in the end, your company processes should be clearly recognizable as CMMI compliant, but they certainly don't have to look like the process areas that the CMMI describes. The CMMI "processes" are referred to as process areas, indicating that the "processes" described in the CMMI documentation are not really to be thought of as processes, but rather as containers for elements that should be found in the work processes of a company that meets the CMMI requirements. It is possible to grab the CMMI book and basically copy the process areas and make a one-to-one relationship between the CMMI process areas and your company processes. It is not necessary, however, and it probably makes much more sense to identify your company processes and then fit the elements of the CMMI process areas into your company processes. I'll get back to this later.
How fast does one mature on the CMMI scale? The SEI states that progressing from one maturity level to the next takes about 18 to 24 months from when a company starts with no processes and until it is ready for an assessment. The figure depends highly on your company, but if you have little experience with process improvement work, don't expect to be better than most others. One CEO who had been directly involved in the CMM (not CMMI) level 2 efforts in his company insisted that they had become CMM level 2 ISO certified within two calendar weeks, and hence progressing to CMMI level 2 or 3 would be a simple task for a company that capable. When we investigated the time sheets, we discovered that this figure was grossly understated: somewhere between 6,000 and 7,000 hours had been spent on the CMM level 2 preparations, and would have required everyone in the company to have put in 90 hours per week. It's good to be optimistic, but don't be delusional.
As you begin, you'll invariably be asked the question: "how much will it save us?" There's no way to answer that question up front, because in order to answer it, you would have to know how much the company is wasting on immature processes and work flows, and how much of that waste can be eliminated. As an expert enterprise architect once told me, just tell them "23%." It's a number that sounds appealing and not too sales-like, and the true figure your company can expect will be anyone's guess anyway.
Levels of Maturity
Search for CMMI on the web, and you'll find the five levels of CMMI:
- Performed. This is where everyone starts: your company is making products and you're earning money, so evidently you're doing something right. But you'd have a hard time describing precisely how you're doing it. Your project teams may be managing by the book, but they certainly can't tell you which book. You're performing, but you don't really know why or how well.
- Managed. At this level, your company's project teams are well-functioning according to ordered methods that are well-documented. There's no guarantee that one project team is managed by the same methods as another team, however, and each time a new project is started, you may find the team reinventing the wheel.
- Defined. This is where all of the methods are well-defined across your company, and all of the projects perform according to those methods rather than figuring them out on their own.
- Quantatively Managed. The projects perform according to the same methods as at the "defined" level, but at the quantitatively managed level the projects will have plenty of hard data to back their decisions and performance. This enables the projects to make sound decisions and quickly identify deviations, and it obviously requires that the defined processes have been followed for a while.
- Optimizing. At the last level, the organization continuously focuses on optimizing its work processes. This requires plenty of statistics from the quantitatively managed level.
Since all companies start at level 1, the CMMI model doesn't state any requirements below level 2. Level 2 is concerned with project planning and processes for managing projects, requirements, and suppliers, and introduces "support" processes that are vital for further maturity: configuration management, metrics and analysis, and quality assurance.
Level 3 introduces a large number of processes. Risk management is added to the project management toolbox, and the project management processes are expanded with processes for integrating separated teams in the management. This level also introduces three processes aimed at defining processes at company level rather than project level. Level 3 also involves processes for constructing products according to well-developed requirements, and for verifying and validating the products.
Level 4 adds processes for assessing objectively how the various processes perform, and for managing according to objective metrics and statistics.
Finally, level 5 provides processes for maintaining an organizational environment for innovation and for identifying and correcting the cause of problems and inefficiencies in the processes.
At each level, all of the processes for that level (and previous levels) must be institutionalized in the company. This means that the processes must become second nature to everyone involved in the processes, much like your morning ritual is probably second nature to you; it's a sequence of tasks that you perform and objects that you use without really thinking about it.
Institutionalization doesn't occur overnight. It takes a while for the employees in a company to get used to new processes to the extent where they believe this is what they've always done. Take note of this, because it means that progressing to the next CMMI level can easily take years.
I've avoided the discussion about continuous vs. staged representation until now. The two approaches aren't really that different, and I think they primarily indicate different company objectives with the CMMI. The staged representation organizes process requirements according to maturity while the continuous representation organizes process requirements according to capabilities. The continuous representation is a recommended order of introducing capability oriented CMMI practices (more on practices later) in order to also reach maturity. Since maturity and capability should go hand in hand, I think the difference is mostly a question of how the CMMI implementation is organized in the company.
Proprietary Language
One of the first things you should learn is the CMMI glossary. Many expressions and terms, e.g., "as appropriate," "establish and maintain," "adequate," "as needed," "consistently," "defined process," etc., may seem intuitively understandable, but have a very specific meaning in the CMMI context.
The CMMI book fortunately includes a glossary of the terms, but its descriptions are somewhat terse and in my opinion do not always clarify the terms.
For example, the explanation of "as appropriate" states that you should interpret CMMI goals and practices so that they work for your organization. This sounds easy enough, but it lends itself to another question: within what limits can I interpret the goals and practices? For such terms, it is a question of getting a proper feel for the needs of your company and making sure you do "not too little, and certainly not too much."
Striking a balance between "too little" and "too much" in terms of company needs versus processes is highly dependent on the nature of your company and I'm afraid also on the personal tastes of the various stakeholders. Too many process improvements projects have leaned towards the "too much" side, and as the one in charge of identifying and defining processes, it is easy to overdo the processes, making them too complicated for the target audience. It depends entirely on your company needs which metrics and which level of measurement granularity to use, what a particular CMMI practices means in your company (for example, SP 2.1, "Review Interface Descriptions for Completeness" in the product integration process area isn't quite the same to a software vendor as it is to a hardware vendor), etc.
For other terms it is easy to miss the point. For example, the term "establish and maintain" is so prone to misunderstanding it that the glossary actually states that the term connotes a meaning behind the words.
You'll find these terms throughout all the CMMI documentation, and if in doubt, always consult the CMMI book, and never assume you can figure out the meaning on your own. This is also true if you're ever in doubt or if you ever forget what some CMMI practice means: consult the book.
Policies, Processes, Procedures, Guidelines, Process Assets, and Tailoring
Much of the CMMI documentation discusses processes and makes little mention of procedures, perhaps in an attempt to avoid the rather frequent discussion of procedures in the CMM (the main predecessor of the CMMI) that had made the CMM appear unapplicably rigid. Procedures are nonetheless the primary building blocks of the CMMI, in my opinion. The reason I think so will probably become clear as I try to structure the various levels of process documentation involved in the CMMI:
At the top level, you have policies. At CMMI level 3, the company must have a policy for each CMMI process area stating in brief terms what major company goals each CMMI process area should meet. In my opinion, you don't have to phrase the policies in CMMI terms, organizing the policies according to CMMI process areas. You may instead want to have policies stating, say, that you must be able to fully recreate all of your shipped product versions, in case of the configuration management process area. Various CMMI appraisers will have different opinions on this.
Next, you have the processes (that is, your actual processes, not CMMI process areas). Each process involves a number of tasks to solve in order to meet certain goals, and it describes which work products are required to perform the process as well as which work products are produced by following the process. It also describes who performs the tasks. There's more to a process than this, but I'm mostly trying to explain where in the big picture you find the process. The process description is kept at a rather high abstraction level, describing what is done; you wouldn't, and shouldn't, know how to perform the process merely by reading the process description.
Procedures clarify the processes, explaining how to perform each step in the process. Your company will soon need several different procedures for the same process step, depending on department needs or project characteristics. For example, one of the CMMI process area steps requires you to estimate the effort required to develop your work products. It obviously depends on the type of work product how you estimate its size and the effort required to develop it, so you'll have different procedures and tools for that same process area step.
The procedures are kept practical. As a rule of thumb, someone that has received training in the tasks described by a procedure should be able to follow the procedure. If a procedure requires rather elaborate instructions, such as the use of a particular tool, you'd refer to instructions in the procedure. Procedures also refer to tools, templates, and guidelines. Guidelines are basically rules of thumb that are used to, e.g., describe considerations that one should make for particular decisions that don't lend themselves well to proceduralization.
Think of the detail level of processes, procedures, and instructions as a match to the skill levels of your colleagues:
- Process descriptions are for the experts that have years of experience, and only need brief descriptions, templates, and checklists. (In my opinion, templates and checklists are invaluable tools for ensuring consistency and avoiding errors and omissions.)
- Procedure descriptions are for the average colleagues that need training before they can follow the process. The procedures describe in somewhat broad terms how to perform a task, in sufficient detail to follow the description with appropriate training.
- Instructions are for the novices, who need detailed step by step guidance.
At CMMI level 2, you basically make up the processes, procedures, etc. yourself. Together, they comprise a business manual for your project detailing how your project team should work on your project.
Then there's a huge conceptual leap to level 3, because when you're moving to this level you should be able to unify the processes across your projects so that they follow the same processes in the sense that what they're doing is the same. All projects conform (mostly) to the same processes, and the company provides a number of process assets that is the company's toolbox for following the processes. You no longer make up the processes or the procedures yourself, and so you don't have your own toolbox anymore. Instead, you specify which process assets you need for each process based on the process assets made available by your company. Your choice of process assets is your business manual. This choice of assets is referred to as tailoring of the process.
Modify your processes and procedures too much at level 3, and it basically means you're moving back to level 2 or level 1. I've heard department managers state that they're just interested in high-level processes, because they don't want to get bogged down by lengthy procedures. They'll just take the processes as inspiration and modify them according to their needs; as they said, "we'll tailor the processes so we can use them so they're completely lean and agile" (or whichever buzzwords the department manager is fond of that makes it sound like he or she keeps a well-trimmed budget).
That's a bad approach for several reasons.
Firstly, the processes are supposed to have been created based on the project and company needs, so they shouldn't need modification. If the department manager says he or she will want to modify the processes, then you probably didn't have the necessary buy-in from this rather important stakeholder when the processes were created.
Secondly, processes state only what to do, not how to do it. For example, "Estimate the size of the work products" might be a good process level description, but as any skilled programmer can tell you, estimation is no trivial task, and it can be performed in many different ways. If the process is to ever be put into practical use, you'll have to know how to follow the process; in the case of estimation, you'll have to know which estimation method and tools to use, among other things. When these department managers don't want procedures, then they don't want their employees to know how to follow the processes, which in turns means that they are basically saying that they don't intend to follow the processes.
Thirdly, tailoring does not mean you eliminate or modify parts of a process as you see fit. Tailoring means selecting those procedures, guidelines, templates, tools, and other process assets that are the best way to follow the process on your project. It does not mean omitting procedures or modifying procedures at will, because that's reverting to level 2 or level 1. Procedures describe how to follow a process, and tailoring means finding the procedures with the best fit for your project. Following the process is mandatory, and your freedom lies in determining how to follow the process within the limits of the tailoring guidelines provided by your company.
You certainly don't do what one project manager I've met thought he could do. He had discovered a specific agile project management style and believed this project management style would allow him to "tailor" the project planning process to omit all of the project plans, including configuration management plans, requirements management plans, risk management plans, verification and validation plans, and quality assurance plans. In short, he was expecting to be the tailor of "the emperor's new process," which was to be so lean you couldn't even see it.
Beware also of the entrepreneurs. They are often highly motivated, but are also highly prone to ignoring processes and procedures, and want to focus on tools and tend to manage "their way," which in practice means a crude level 1 way. They can be problematic both when you identify and describe your processes, and when eventually you deploy the processes throughout your company.
I'm not very willing to accept arguments stating that you're a company with rather different types of projects, so you can't use the same processes in one department as in another. Yes, you'll have different ways of doing things in your projects. Most likely many of your procedures are going to be different. The processes are going to be mostly the same, however, and unless you want to fail the assessment, the CMMI process areas must be identifiable in your processes. Remember that probably much bigger companies than yours with highly complex products are able to follow the same processes throughout the respective companies, so if you think your company can't, then probably you don't have sufficient insight into either your own company, your processes, or the CMMI process areas.
There are times when a practice may be very significantly reduced in scope or in rare cases ignored. It seems reasonable that small companies will have processes and procedures that are relatively simple while large corporations will have a huge array of different procedures for following the processes.
You can't leave any process areas out, except the supplier agreement management process area in case you don't integrate components provided by other suppliers into your products.
Goals and Practices
Each CMMI process area aims to meet a few goals. These goals are mandatory: your company must demonstrate that those goals are met, or you will not be compliant with the process area.
The CMMI process area goals are met by following a number of specific practices (SP) and generic practices (GP). These practices are "recommended," which for all practical purposes means mandatory. It means you can omit a practice, but you had better have a very good reason for doing so, and you should describe what you're doing instead that's just as good. Finally, there are optional practices. I prefer to think of them as suggestions to what you might do, and they serve well as clarifications of the recommended practices.
Specific practices are relevant only for the particular process area. For example, SP 1.3, "Establish Verification Procedures and Criteria," of the verification process area, is obviously relevant for verification only.
Generic practices are practices that are essentially the same regardless of process area. For example, GP 2.8, "Monitor and Control the Process," states that the progress and performance of each process area should me monitored, and that corrective action should be taken if irregularities are detected. This is true for any process area, no matter if it's verification, configuration management, or project planning. You should, in fact, make sure that all of your processes are monitored and controlled this way, not just the process elements containing the CMMI process area elements.
Be careful with the generic practices. They are the same for all of the CMMI processes areas, and it's easy to think this means you have a small total of ten generic practices to follow (at CMMI level 2). That's an understatement, because you have seven process areas at level 2, and each of the ten generic practices applies to each process area. It's not true to say this yields 70 practices, though. For example, GP 2.5, "Train People," means that your company should train to people to follow the appropriate procedures, and while certainly proper training applies to all processes, you probably wouldn't add a training task in each process; instead, you would probably have some sections in some processes taking care that your employees receive the needed training.
Several of the generic practices will seem redundant or self-referencing. For example, GP 2.2, "Establish and maintain the plan for performing the process," means that each step in your process should be planned so you know how long it takes, when it is to be performed, and which resources it requires. This seems redundant for the project planning process area, because the project planning process area is concerned with just that: planning. But in fact the project planning process itself should also be planned; for example, part of the project planning process area includes estimation of the size of the work products to be developed. Estimation is not a trivial task, however, and may involve specific people whose time must be allocated. You therefore need to plan the estimation, and when you've planned the various tasks involved in the process planning process area, then you'll know the effort required by the initial planning phase of the project. You'll find similar apparent redundancies for project monitoring and control, configuration management, etc.
Document Your Existing Processes First
It is tempting to grab the CMMI book and apply the process areas as they are, that is, as if they were processes, to your company at the level of detail matching the requirements of your organization. This isn't entirely wrong, of course, and you can (mostly) follow each process linearly in a waterfall-like fashion. For example, the project planning CMMI process area involves a set of specific tasks that you'll most likely want to perform, and probably also roughly in the same order as the practices are described in the CMMI process area. I suspect it is the waterfall-like form of the CMMI process areas that have led to the myth that CMMI cannot be combined with various lean practices.
I think there's a better approach, though, and I'll assume you're starting from scratch.
First of all, you need a group of people responsible for describing the company processes. This group must be assigned one hundred percent to this task, because otherwise they will soon find themselves working on other projects, neglecting the process work. In addition, the group must have full sponsorship from the company, which means time and resources must be allocated for the group. Nothing weights less than a promise.
I cannot stress the importance of sponsorship enough. There must be time and budget plans for the process improvement work and according allocation of resources. It is not possible to perform process improvement by assigning process improvement efforts as secondary tasks that are to be solved when occasionally there is a little spare time in the company during low-stress periods.
If your management won't allocate the necessary resources to your CMMI process improvement efforts, forget you even tried. Try to find out why your sponsor wants the CMMI. If your sponsor wants to improve your company's performance and maturity, then maybe your sponsor understands the importance and value of CMMI. But if your sponsor's primary goal is to receive a CMMI level 3 (or whatever) assessment for sales purposes, then probably you don't really have the sponsorship needed for your efforts. I think your sponsor should not only tell you about their commitment but also their customers and the general public. If they're willing to do that, then they'll have something at stake that may keep them motivated.
It does cost money to define, deploy, and institutionalize processes--both in terms of salaries, appraisal expenses, and opportunity cost, that is, the opportunities missed because key personnel was working on processes--but the payback should be obvious: reduced overhead, reduced defect rates, re-use, and better planning are just some of the benefits of well-defined processes. Think of it as an investment similar to education: if you think education is expensive, try stupidity.
Secondly, make contact to a CMMI appraiser who will perform the CMMI appraisal of your company. There are several advantages to getting in touch with him or her early. Firstly, the appraiser can help you interpret the CMMI, which can appear somewhat cryptic at times. Secondly, the appraiser can help you ensure that your processes meet the CMMI requirements so you won't discover until the time of the appraisal when process changes are going to be expensive compared to getting it right the first time. Lastly, and perhaps most importantly, your appraiser will be familiar with your company processes, company needs, and your internal stakeholders, and will spend less time understanding your business and processes and learning to communicate efficiently with your colleagues.
The group should familiarize itself carefully with all of the CMMI goals and practices, including the optional practices that may not apply to your company. Make sure you understand what they all mean. You may think terms such as "GP 2.8, Monitor and Control the Process" for some process sound evident or easy to follow at the time you read the books, but did it occur to you that this could imply that project managers must track their progress in the process and take appropriate action if they're deviating from the planned progress, and that this tracking task must be added to the company processes? Similarly, "SP 1.2, Establish Estimates of Work Product and Task Attributes" may sound reasonably easy and intuitive, but do you know what is meant by work product and task attributes? And does "attributes" refer to both work products and tasks, or does it refer to just the tasks? Margaret Kulpa's and Kent Johnson's book, Interpreting the CMMI, provides an excellent walk-through of the various processes, and I recommend you buy it.
Once the process group understands in detail what all of the CMMI practices entail, forget about the CMMI processes for a little while. You're supposed to create processes that help your company, not to create a company that follows specific processes.
If your company is at a low level of maturity, don't expect that your colleagues will to be too happy with the prospect of procedures. Your successful implementation of processes and procedures depends on stakeholder buy-in. If a procedure involves a number of people, all of them must be able to see that the procedure is working to their advantage. They must understand why the procedure helps them directly or indirectly. If they feel the procedure is working against them or that the procedure is useless compared to whatever they happen to do instead, that is, if you put on the "the procedures aren't here to help you; you're here to follow the procedures" attitude, then they won't follow the procedure. The combination of will, violence, and vaseline may be required in some cases, but try to do this as little as you can.
Fortunately, you have somewhere to start. Recall that at level 1, your company is performing. You don't know exactly why or how, but something is evidently right somewhere. You probably have skilled colleagues working together, and somewhere in the team there has to be agreements and negotiations that lead to a product in the end. There's something behind their noisy work behavior that can be worked with, and that's your processes. Your task is to identify them and describe them.
In addition, you know which processes you should focus on, namely the ones that correspond to the CMMI level you're aiming for. If you're aiming for CMMI level 2, you should focus on managerial processes and "support" processes and try not to get too technical with the people that are constructing the products, because that's reserved for level 3.
The development of the process descriptions is possibly the second-most difficult task you'll face as responsible for CMMI in your company. It is largely a question of dealing with people, and it is a situation where everyone has an opinion that must not just be heard--it must be satisfied. Dealing with people can be a challenge in engineering environments. Books such as Kathleen Reardon's The Skilled Negotiator or Rick Brinkman's and Rick Kirschner's Dealing with People You Can't Stand may be helpful. (I'm not implying that engineers are people you can't stand, but they can be an opinionated bunch of people who will rather become grumpy afterwards than tell you what they think in terms of processes and procedures, and you'll have to deal with that.)
Alec Sharp's and Patrick McDermott's book, Workflow Modeling, is a very practical approach to process modeling. The other books I've read on process modeling have focused on how to describe the models in precise terms such as using UML diagrams, but I feel this is one of the less important aspects of process modeling when it comes to modeling the processes of how people work. Your focus should stay on making people understand the processes, not on the exactness of the format of the process description. Put a little bluntly, you model your company's processes because you want to communicate with the people performing the work, not because you want an accurate model useful for programming an army of robots.
Your colleagues know something, but they're not sure what it is, or how to say it. You don't know it, but with Workflow Modeling you'll have a significant number of skills and tools to find out exactly what your colleagues are doing as they develop the products.
Develop the process descriptions in enough detail so that your colleagues know what to do (the process), and to a reasonable extent how to do it (the procedures). You'll have to go all the way down to procedures in many cases, because otherwise you're going to miss some of those people that are involved in the process and must be satisfied. It won't be lost effort, because eventually you'll have described these procedures and put them to use anyway. (You know you've gone too far when you're writing "From the Tools menu, select Preferences ... .")
You don't want to consider specific instructions, guidelines, checklists, and templates at this stage, but you'll probably want to know the major features of the tools used. Just keep in mind that your current process is the one that you're about to improve, so don't get lost in details that are bound to change.
Make sure the process descriptions explain what your company is doing right now--this is the so-called "As-Is" process. If you're expected to measure whether applying CMMI to your company will optimize various key metrics, this is also a good time to introduce metrics in the As-Is processes provided your company is mature enough to gather such metrics. These metrics can be compared with the metrics after the processes have been improved, and you'll be able to see the result of the change in terms of these metrics.
You may want to get familiar with Enterprise Architecture, which is an excellent framework for modeling both business strategy, informations systems, processes, change management, and knowledge management. I haven't been able to locate any "perfect" book on Enterprise Architecture, but I suggest An Introduction to Enterprise Architecture by Scott A. Bernard.
After Documenting the As-Is Processes, Apply CMMI
Eventually you'll have documented your existing company processes, and the next step is relatively easy. Since you're familiar with the CMMI requirements at this point it should be fairly evident to you where the existing processes do not live up to the CMMI requirements. Workflow Modeling includes guidelines on how to improve existing processes, only do you not have to be particularly creative and innovative, because the CMMI model already states what's required, and the company policy for each CMMI process states which goals each process must meet.
But remember: no matter what you add to, or change in, the existing processes, all of the people affected must think it's a good idea.
It's easy to forget the company policies for CMMI processes, so remember to ask yourself the question: "does this new process description meet the goal that (insert policy for the appropriate process)?" If the process does not meet the company goal, the resulting procedures will cause the employees to work on something that deviates from the company goals, and you don't want that to happen.
Don't worry too much about "getting it right" the first time. You should avoid obvious errors and non-compliance with the CMMI practices, of course, but don't gold-plate the processes. Remember that no matter what you do, it will always be possible to improve the processes (after all, that's what level 5 is all about), and you can always fix minor issues or clarify procedures and instructions during what will hopefully be your periodical process adjustments. At some point, good enough is good enough, and going into too much detail may deviate too much from your current processes, making it cumbersome to deploy the process changes in the company. Change hurts, so don't change too much at a time lest your colleagues be writhing in regulative pains.
You may find that in many cases you can't describe the necessary procedures; for example, the CMMI book doesn't describe in detail how to estimate the size of a work product. This is where your colleagues must apply their professional skills, and where you may have to consult experts on a variety of methods. For example, the requirements development area may lead you to study use cases, joint application development, etc., which may require skills that you do not have in your organization. For software development companies, consider Steve McConnell's book, Rapid Development, your bible--it is a tutorial on most of what you'll need on the various development practices.
Various surveys indicate that the configuration management process area appears to be a rather neglected set of practices in many companies. Configuration management is also a generic practice for all processes. Be careful not to think that revision control using tools such as CVS, Subversion, SourceSafe, etc. will suffice. Revision control is vital for configuration management, but configuration management also involves lifecycles for changes and strict use of change control. Chances are that the configuration management process area is a good place to start in your company.
When you're about to move to level 3, I suggest you start with the CMMI processes areas named "Organizational Process Definition" and "Organizational Process Focus." These processes areas describe how your company will define your processes for use across the company, and how you'll maintain your processes, respectively.
This looks like a chicken-or-the-egg situation, because you're going to define your process by following the very process you're about to define. In practice it's not that bad. You're starting from scratch, and that means anything you do is your best bet on a process at the moment, so you have your egg right there. You probably can't find a proper place in the company processes for all of the organizational process definition and organizational process focus practices to begin with, but no-one says you must finish one process area completely before moving to another process area, so don't consider this a problem. Also, the other CMMI process areas can help you define the processes. If you think of your process definitions as work products that you're going to release, then identifying and writing the processes are related to the requirements development and technical solution process areas, and planning and maintaining the work are related to the process planning and process monitoring and control process areas. Deployment of the processes (more on that later) can be thought of as integration and configuration management process area tasks.
Next, work on the organizational training process area. This is the process area that will be used to train people throughout the company in your new processes and procedures, and at CMMI level 3 your colleagues will need lots of training owing to the large number of processes areas introduced at level 3. If you need other people to work on the process definition and process focus areas, you may consider working on the organizational training process before you even begin on the process definition and process focus processes. This is reasonably safe, because there is probably not going to be much variation across projects in terms of how organizational training works. (The organizational traning process area focuses on the organization's role in training, not on project specific training.)
Once the organizational process definition, organizational process focus, and organizational training process areas are reasonably finished--that is, when those that are responsible for the company processes meeting the requirements of these process areas know how to follow them--start on the remaining processes.
In my opinion, it is very important to work generic practices 2.8 and 2.9 into the processes as early as possible. GP 2.8 means you monitor how well the process itself performs; e.g., how much effort is spent on implementation versus effort planned, and taking corrective action when significant deviations are detected. GP 2.9 means you (or others) monitor how well you stick to the process and take corrective action if necessary. If you define good metrics for these generic practices (and that implies you'll have to work hard on the metrics and analysis process area as well), not only will it be readily apparent how well the processes are performing, it will also be your sponsor's tool for keeping focus on the processes, with help of generic practice 2.10, which states that upper management must be kept aware of the process performance.
Artifacts
A CMMI level assessment involves an inspection of your company's processes, most likely according to the so-called SCAMPI method. The goal is to determine whether the CMMI practices are described in your company's processes, and whether your company follows these processes. The former is easy enough, because that's basically your business manual. The latter is a little more involved, because your CMMI assessor will have to search for tangible evidence--the so-called artifacts.
An artifact in the CMMI context is something that proves that a particular CMMI practice has somehow been followed. For example, an issues list with action items assembled from a peer review of a document is (probably) evidence that SP 2.2, "Conduct Peer Reviews," of the verification process area has been followed.
For each CMMI practice, at least one direct artifact and at least one indirect artifact must be identified. Apparently many people are confused by the terms "direct" artifacts and "indirect" artifacts in the SCAMPI method. The distinction is somewhat unclear at times, but as a general rule, a direct artifact is a work product that is a directly desired output of a particular practice, and an indirect artifact is a work product that doesn't really have any value by itself, but which could only have been created as a byproduct of performing that particular practice.
For example, the call for review or the reviewers' time registrations indicating time spent on a review might quality as indirect artifacts, because the existence of such evidence wouldn't make sense unless the peer review practice had been followed. Hence, an indirect artifact can be a work product that was necessary to produce the direct artifact and useless for other purposes, an activity that wouldn't have made sense unless the practice was followed, or some secondary work product that would only appear if the procedure was followed.
CMMI SCAMPI Distilled by Dennis M. Ahern, Jim Armstrong, Aaron Clouse, Jack R. Ferguson, Will Hayes, and Kenneth E. Nidiffer explains the SCAMPI appraisal method and includes a long appendix with a list of example artifacts for each CMMI practice.
Deployment
Deployment means that your new processes are put to use in your company.
It is reasonably easy to deploy new processes and procedures in individual, independent projects, as is the case at CMMI level 2: you just state which processes and procedures are to be followed, and that's that. If this means you'll have to update work products from an earlier phase of the project, then these updates must be planned, of course.
It is much more complicated at level 3 where the same processes and procedures must be deployed throughout the company. The organizational process focus area requires you to plan the deployment, and there are several issues to be considered. Modeling the company according to an Enterprise Architecture framework pays off here.
If you expect most of your current projects to finish within a foreseeable future, maybe your deployment can simply state that: "All new project follow business manual version 2.1," but don't expect to be this lucky.
Most companies will have several active projects in different stages of completion. Some projects may not be expected to finish until years into the future. It is not necessarily desirable to rework all of the project's work products to comply with the new procedures, and you may even be contractually obliged to stick to a particular set of procedures. How does one deploy process changes to active projects that are following known procedures?
There's no simple answer to that question. You can probably deploy some process changes in some of your active projects, and although this will almost certainly help institutionalize the new processes, these projects won't otherwise help in your CMMI assessment, as the projects are not compliant with the next-level CMMI processes until all of the CMMI process areas for that level are found in the projects.
In a sense, it is all a question of configuration management and requirements management at project portfolio level where you'll have to evaluate the effect of the process changes on each project and maybe determine how a project should "branch" (in the language of configuration management) and subsequently "merge" at a later stage. Think of it as if you're maintaining different versions of your business manual at the same time.
Before you roll out changes throughout your company, conduct pilot runs. Try a new procedure on a guinea pig project where the risk of failure will not have significant impact, collect feedback on the effectiveness of the procedure, and then determine whether it should be changed before it is deployed throughout the company. Another pilot run may be necessary.
Monitor and help the test subjects carefully as they try to follow the new procedures. I find it advantageous to organize procedures meant for pilot runs as "checklists" where possible, in the sense that it should be possible to understand when some step in the procedure causes problems or should be changed or omitted, and in all cases why.
Also, remember that the project must receive sponsorship as the procedures can be expected to require some initial effort on the project. Time and resources for the pilot runs must be planned and allocated.
Sponsorship is also required on the actual deployment after the pilot run has completed successfully. The deployment will fail unless you obtain sponsorship for the effort required to deploy the processes.
Your sponsor may have found it acceptable to spend resources on the definition of processes, but the prospect of decreased productivity in the various departments while new processes are adopted may cause the sponsor to withdraw the funds allocated. Prepare your sponsor in the very beginning of the CMMI efforts that this will happen.
Sponsorship must also exist at the lower levels of management. The department managers are probably expected to maximize their earnings, and as long as their success is measured by that metric, then they won't spend effort elsewhere. A different metric must be introduced for the department managers' success: a metric indicating process compliance, and it must be more important to their sponsor than the earnings metric. This is one of the reasons why I stressed the importance of being able to monitor the processes in the discussion of the To-Be processes.
If the department manager truly wants process improvement and is willing to allocate the required resources, the department manager will also want to monitor the process compliance of his or her subordinate managers, who in turn will be motivated to monitor the process compliance of their teams.
Start early with the supplier management process if you want your level 2 assessment as soon as possible. This process may not be your most important process, but remember that the CMMI assessment requires you to demonstrate artifacts collected for several projects. This can be difficult if you have only a limited set of suppliers, or if only few projects make use of suppliers. Starting early with the supplier management process may help you gather enough artifacts for the assessment.
Institutionalization of the To-Be Processes
Institutionalization means that the processes should become second nature to all of the involved stakeholders. They must feel that this is how they've always done things in your company.
Institutionalization begins at the moment a process is deployed, because people will now begin using--and hence getting used to--the process. Successful institutionalization requires a bit more, however.
I believe institutionalization is the hardest part of the CMMI process improvement, primarily because it requires sponsorship over a long time with little sign of returns of the investment. You'll also have to convince your sponsor that his or her employees must receive training, and projects will have to change their plans according to the deployment plans. Again, the first keyword is sponsorship.
The second keyword is training. For each new procedure, the appropriate people must receive appropriate training. Note my use of "appropriate." It depends on both the role played by the various stakeholders, their levels of experience and expertise, and the nature of the procedure. For example, if a new peer review procedure is deployed, training may be a simple walk-through of the procedure, followed by reminders of the major steps in the procedure the first several times the procedure is used. If a new requirements development procedure calls for the use of use cases, perhaps the estimators must take classes to learn how to effectively apply use cases. (By the way, I highly recommend Use Case Modeling by Kurt Bittner and Ian Spence for that.)
In all cases, I think the relevant stakeholders should receive a class introducing the company processes, explaining why the processes are formed the way they are and which benefits they introduce. Make sure that each person understands why he or she is better off with the new processes. This can be a challenge in the early stages of maturity where your colleagues may not appreciate that the result of bureaucracy or an apparent inefficiency in one area is desirable if it increases overall efficiency. Part of the institutionalization at an early stage of maturity is a change in company values from hero worship to valuing compliance to processes. It is tempting to be happy with one man's superior performance, but an average team that works according to efficient processes is much more productive than a disorganized team with one hero. Such a change may be easier in some cultures than others. Expectations from the sponsor will trickle down through the company, so make sure the sponsor himself or herself desires this change of values.
Many procedures require specific skills, such as procedures for estimating, implementing the technical solution, planning, developing requirements, analyzing metrics, delivering training, etc., and many tools require training as well.
You don't necessarily have to organize all training as classes, of course, and you may instead find it advantageous to employ several training methods, including mentoring, workshops, e-learning, etc. I have found it very effective to briefly reiterate a procedure before it is put to use; for example, if a formal peer review procedure is followed, you might want to remind the reviewers of their tasks and remind them to consult to the procedure. Eventually they'll do it on their own.
But never expect people to "just know" how to follow the processes, or even to follow them at all, just because you tell them to. Putting a procedure to use isn't training but experience, just like one gets used to a tool.
Over time, hopefully everyone will become used to the processes to such a degree that the processes will not begin to fade or deteriorate as soon as management forgets to remind the employees of the importance of the processes. This is when you're ready for a CMMI assessment. Your assessor should be able to help you determine when you're ready.
Note: the author of this article is not affiliated with the SEI. Opinions expressed in this document are those of the author.
If you liked this post, share it with others:
Changing LINKS GeekySpeaky: Submit Your Site! Blog Directory
Ratings on this site are powered by the Ajax Rating plugin for Movable Type.
Recent Comments
Solomon on Movable Type Plugin: Sociotags: Ole, I ins
Ole Wolf on Movable Type Hack: Visitor Stats Detailed View: I'm pretty
Scott on Movable Type Hack: Visitor Stats Detailed View: Ole, As M
phichit on Joomla Plugin: Curvaceous: You must b
Solomon on Movable Type Plugin: Sociotags: Ah, bummer
Ole Wolf on Movable Type Plugin: Sociotags: Solomon: y
Solomon on Movable Type Plugin: Sociotags: Would like
Ole Wolf on Movable Type Plugin: Joomsayer: Joe: yes,
joed86 on Movable Type Plugin: Joomsayer: I have cus