CMMI

The CMMI IS Right For You; However . . .

As more organizations adopt the CMMI, the breadth of adopters is moving from the large DoD/Aerospace companies to more midsize and smaller organizations.  Equally, organizations from different market sectors are adopting it, and they don’t all have the same safety-of-life critical applications that the original DoD/Aerospace adopters had. 

This begs the question; if I’m not a large organization with safety-of-life critical applications, how can I best use the CMMI without overly burdening my organization with many potentially great but often unnecessarily cumbersome practices, or rearchitecting my entire process set?

Finally, some common sense solutions.

1. You don’t have to re-architect your entire process set to comply with the CMMI.  In fact, you can be CMMI compliant without even knowing the CMMI exists.  If you’re already running your software business as a business, you’ve probably got most of the basics covered already.  Your challenge is to: map your processes onto the CMMI to ensure you’ve addressed all the best practices, create or enhance processes where they are missing or weak, implement those new or newly enhanced practices, and follow them long enough to demonstrate that they are working better than the previous ones.
2. Go Slowly.  We know you’ve got the task to achieve CMMI MLX by Tuesday, regardless of what all the industry data show.  The SEI is beginning to take a very serious look at organizations that show Maturity Level Progress that is out of alignment with what the statistics show as a reasonable time to improve.  Go Slowly.  Conduct a baseline appraisal to show what your real starting point is.  Plot a path from that point to your target.  Defend the plan as reasonable, based on the available data.
3. Start Small.  Don’t bite of more than you can chew.  People, in general, are resistant to change.  Don't overburden them with too many new ideas at once.   We frequently find that the most successful strategy is to start off with only a couple of improvements.  I like to tackle the most significant challenge, and an easy challenge.  The most significant challenge must be addressed due to its potential for great positive impact.  The easy challenge will demonstrate the validity of process improvement at making things better, and it will typically do so, quickly.
4. Run the Process Improvement Initiative as a Project.  The Process Improvement Project needs Sponsorship, Support, a Plan, Resources, Schedules, Deliverables, Quality Checkpoints, Measures, etc. just like any other project.  To not give it the benefit of all of these project characteristics, is to all but doom it to failure.
5. Availability is NOT a skill.  If you are considering allocating 5% - 7% (typical) of your software development budget to achieving CMMI compliance to be both more successful, and to be able to bid on future work, don’t just take whoever is available on the bench to staff this activity.  Software Process Engineering is a discipline with required skills and qualifications just like any other engineering discipline.  The biggest challenge in software process improvement projects is that it is a people challenge in a technical environment.  Make sure the resources assigned have both the technical and soft skills required to make the project a success.

Policies, Processes, Procedures, Projects, Plans, Products

Often when I provide initial consulting for an organization I am frequently shown procedures when I ask for processes, or shown a schedule when I ask for a project plan.  As a result, this month's blog presents some of the basic terms of process improvement.

Policies, Processes, Procedures, Projects, Plans, Products, People -- Huh?????  What's with all the words that start with P?  Don't be fooled by simple alliteration.  This is complex stuff and can lead to long, boring and unproductive meetings if you try to wing it.   As a consultant, of course, I encourage any of you wishing to attempt process improvement to seek professional help (and I only mean that in the nicest way).  For those brave souls out there charged with doing this on your own, here are some definitions to help clear the fog.

Policies -- The vehicle whereby senior management communicates their commitment to the new way the organization will do business from this time forth.  Policies emphasize the connection between the organization, its business goals and objectives, the individual projects within the organization, and how they all work together.  They also put forth a guiding principle that the organization can follow and achieve.  One overarching policy statement is usually sufficient if it references an organizational process document.  Try to avoid writing a separate policy for each process.
Sample Policy Statement -- We are committed to the effective management of our software development activities as the key to improving quality, productivity, and predictability for the benefit of ourselves, our business partners and our clients, customers and users.  To support this goal, all software projects are required to comply with the Company's Software Process Framework (SPF), which outlines our software project development and management processes.  Reviews, audits and assessments will be used to verify compliance and as the basis for improvement.  Training and tools will be provided as needed to enable and assist in compliance.

Processes -- Process is a tool whose purpose is to assist an organization in improving its performance in critical business areas.  The process is the means by which you achieve a business end; it is not an end in and of itself.  The process is not the product.  Too often an organization will set up a large process improvement group and this group becomes a goal for the organization and they lose sight of the fact that the organization needs to perform the work, and the process is just a tool.  Processes should be written at such a level that a skilled practitioner in the art should be able to pick up the process and have a good idea of how the organization does business.  Processes are the ordered steps followed by people, using tools, in accordance with standards, to convert inputs (either given to them or derived by them) into expected outputs.

Procedures -- Procedures are the lower level steps that guide practitioners in how to perform a specific task.  For Example:  the process might instruct the analyst to perform analysis using the one of the acceptable Object Oriented techniques.  The supporting procedures might explain how to select from among the various acceptable techniques based on the complexity and criticality of the project, and might then further specify how to perform that technique or refer the practitioner to the textbook wherein the technique is further described.

Project -- A project is the means by which an organization accomplishes its primary objective of producing goods or services in exchange for money (usually).  Projects have a specific start and end and are undertaken for a specific purpose, therefore, a project is a temporary endeavor undertaken to provide a unique product or service.

Plans -- Plans are the glue that binds all of the components of an organization into a roadmap for accomplishing a project.  A plan essentially states who will do what, by when, for how much, to what degree of quality, and in accordance with what standards, procedures and practices.  Other nice to haves are a statement of purpose, a description of the organization (including detailed contact information) and its geographic distribution, a description of the roles and responsibilities of the personnel who will be participating on the project team, various subordinate plans (risk, quality assurance, configuration management, measurement, communication) and a waivers, variances, exceptions, and escalation mechanisms.

Products -- Products are those entities, artifacts, documents, etc. that are produced as a result of following a process or procedure.  Products are the result of executing a series of task steps on the inputs.  There is no sense in performing work that does not result in some sort of artifact that can be examined for quality or usefulness and, upon a satisfactory finding, used for a purpose.  A product is a tangible artifact that your customer (either internal or external) expects you to deliver to them so they can use it (implies time, budget and quality conditions and constraints).

People -- It is essential that all participants on the project team know what roles they will be fulfilling, how long they will be fulfilling them and for what percentage of their time they will play each role.  There are many roles on a project and all contribute to the successful outcome.  Some roles to consider are:  senior manager, resource manager, project manager, architect, analyst, designer, coder, tester (many flavors), quality assurance, configuration management, trainer, measurement specialist, process specialist, customer, user, client, marketing, sales, accounting, help desk, field service personnel, installers, repair staff, system engineering, hardware engineering, etc.  It is easily imaginable that all of these roles and more could be involved in a single software project.  It is also easily imaginable that one person could be playing several roles on a single project.  People are the resources that provide the energy that propels the project toward completion.

Now that you have the definitions, you may be wondering what the next steps are.  Just remember, you don't have to go it alone.  Please feel free to contact me regarding process improvement and project management consulting, appraisals, training, and staffing on an as needed basis via phone, email or onsite.

Until we process again,

Is There a Business Case for Appraisals / Process Improvement ?

The prime and probably only justifiable business driver for starting a process improvement effort is if it will adequately answer the question, “HOW WILL THIS POSITIVELY IMPACT MY BUSINESS?”  In other words, will this effort save/earn my organization more than it costs?  The answer to this simple question comes in many shades of gray.

·        Your prime customer says you must start a process improvement effort and achieve a certain objective measure of success to be considered for future work,

·        Your management wants to become more efficient so you can more easily beat out the competition for lucrative contracts,

·        There is dissatisfaction in your external customer base due to the number of errors produced and delivered or because the delivered product fails to meet the customer's expectations,

·        There is dissatisfaction within your own organization due to smokestack organization and lack of communication within the organization.

A model framework based software process improvement effort produces real bottom line results in all of the areas mentioned above. The available data show:

1.      Decreases in delivered defects,

2.      Increases in the number of defects caught earlier in the life cycle,

3.      Productivity gains in the number of delivered source lines of code,

4.      Improved internal communication,

5.      Decreases in estimated delivery schedules without increasing schedule risk, and

6.      Business Value Ratios (Return On Investment (ROI)) of anywhere between 4 & 8.8 to 1. Conservatively speaking that translates to $5.00 returned for each $1.00 invested, or approximately a 5:1 ROI!

To get that kind of return you’d probably have to invest a huge amount of the organization’s assets. Not So.

On average, in a one hundred person IT Organization, you’d need to do the following:

·        Initially allocate funding in the amount of about a mid level developer’s starting salary, and

·        Free up just three to six people or their equivalent to maintain the effort on an ongoing basis.

Managed just like any other project in your organization, your Process Improvement Project will produce positive business results for your organization and will continue to do so for all of the other projects in your organization as well.

Let’s Have an Appraisal – or – Won’t That Make Us Later / More Over Budget (Time, Money)

Although misplaced, the first question I usually hear from project managers concerning a software process improvement effort or more particularly a software process appraisal is how much later will it make us, or how much over budget will it put us.

Internal Costs

Budget Assumptions:

1.      An average time for a first time appraisal, inclusive of all training, briefings, interviews, etc. takes about 7 calendar weeks of labor from start to finish.

2.      The appraisal team will be made up of 6 members of the organization being appraised.  Each of these people will be dedicated to the effort for 200 hours over the 7 weeks.

3.      Approximately 50 people from the organization will be interviewed. These people will need to allocate about 4 hours to the appraisal distributed during weeks 6 and 7.

4.      The “average” organization has 100 people that develop or manage software.

5.      An “average” software development project or release delivery is 6 - 9 months long, or around 7 ½ months on average.

Computations:

1.      7 1/2 months of effort for 100 people is 130,000 hours of organizational effort.

2.      The effort required for the appraisal is 6 people x 200 hours + 50 people x 4 hours = 1,400 hours.

3.      1400 hours / 130,000 hours = 1.08% (That’s right, just a shade over 1 %)

Conclusion:

During the 6 - 9 months of a typical organization’s project schedule, the organization will be impacted to the tune of around 1% of its project-based effort. The cost of an appraisal is in the noise level with respect to the estimation accuracy of both cost and schedule. Therefore it can be concluded that an appraisal will not cause a project to be any later than, or cost any more than if no appraisal were performed.  Most project managers I know wouldn’t bet their paychecks that their cost or schedule estimates were accurate to within 1%.

How To Calculate The Total Cost Of An Appraisal:

• Lead Appraiser fees vary; however, $75,000 can be used as a working figure.

• Six weeks of expenses (Airfare, Room, Board, Vehicle, Supplies, Shipping)

Fully burdened costs for 1400 hours of effort from the organization. This number might increase depending on how many people over the minimum attend the Introduction to Software Process Improvement and CMMI class.

This works out to not more than $100,000 for the Appraiser plus your organization’s costs

How About The Costs Of The Continuing Software Process Improvement Effort:

General rule of thumb data puts the costs of a continuing software process improvement effort at somewhere around 5 percent of the software budget.  In terms of people, you would need a Software Engineering Process Group (SEPG) or equivalent that is 5 people per 100 developers and managers. The SEPG is composed of process people, software quality assurance people, configuration management specialists, measurement folks, etc. These are the types of people developing, improving and assuring that the proper processes and procedures are being followed during the project’s lifecycle phases.

How Do I Get Started?

With a potential ROI of 5:1, the best question might be, how can I get started right away?

The easiest way to get started is to conduct an informal appraisal of a selection of your organization’s projects to see if they are in compliance with your own organization’s standards for the management and development of projects.  Secondly, compare the organization’s standards with an industry benchmark such as the CMMI.  Finally, compare the differences and put together a plan for closing any gaps.

The Basics Of Software Process Change / Improvement

A process is the system of rules/methods and tools that people use to convert the inputs given them (by customers, users, themselves) into the outputs expected of them (by their customers, users and managers.)  The Capability Maturity Model Integrated (CMMI)(r) concerns itself with the rules portion of the process triangle and leaves the selection of tools and personnel up to each individual organization.

 

The CMMI provides both staged and continuous representations by which organizations can gauge their process maturity against an industry accepted reference model.  If an organization wants to increase or improve its process maturity it will have to initiate a Software Process Improvement (SPI) effort.  In order to be successful, there are several basic principles of software process improvement that should be followed.

The Basic Principles Of Software Process Improvement

• Major changes must start at the top – It’s all well and good to try to get a grass roots process improvement effort going, and it may make you feel better; but to really be successful it takes the management’s approval, encouragement, and support.  In fact, if management is not a continuous visible presence supporting the process improvement effort, it is highly likely that the initial feel good glow will shortly be replaced by cynicism and discontent.
     
• The process, not the people, should be fixed – If an organization has no clear cut roles and responsibilities and guidance on how to perform different roles, there is the tendency to lay the blame for lack of success at the feet of the people who must do the work.  Nothing could be further from the real situation, which is, the failure of management in fulfilling its obligation to the staff in the area of clearly stating their expectations as to how each person is to do what is expected of them and by when.
      
  
• Improvement must be continuous, else stagnation occurs, followed by decay – Without periodic inputs of energy (training, money, encouragement, reward, incentives, etc.), the continuous process improvement system will behave much as any other system in the real world.  If you don’t paint your house it will rot.  If you don’t work on your relationships they will fail.  Continuous process improvement is just like any other system; don’t expect it to behave any differently.

Using the CMMI as your framework for adhering to the basic principles of software process improvement will drive your organization in the direction of heightened software process maturity.  This in turn will significantly improve the chances of meeting your project's cost, schedule and quality targets.

If you have any further questions about software process improvement, appraisals or training, please  feel free to email me.

 

Staged or Continuous that is the question

Clients often ask me whether to implement the Continuous or Staged Representation in the CMMI.  I usually tell them not to worry too much about which representation, as it will all come out in the wash eventually.

The Continuous Representation allows you to select the order of improvement with respect to individual PAs in the model.  The Staged Representation allows you to "select" a preselected grouping of PAs.

In actuality, you will select the PAs to implement in the order of the significance of the problems you are trying to address within your organization.  Once you've worked off the most significant problem, you'll pick the next, and so on.  After you've worked off all the significant problems associated with the PAs in Maturity Level 2, you'll want to have an appraisal.

The appraisal will in all probability be a Staged Representation appraisal as that's what the overwhelming majority of all appraisals conducted are.

So... you will most likely use the Continuous Representation to improve and the Staged Representation to appraise.

If you have any additional questions, please feel free to contact me at david.greer@americansystems.com.