Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Does CMM really work?

3 views
Skip to first unread message

Frank Sch.

unread,
Feb 25, 2001, 10:28:06 AM2/25/01
to
I often wonder...
do companies reach a higher level of quality THANKS TO or IN SPITE OF their
CMM efforts?

I also often wonder...
does a significant part of the (really) high quality companies have a
certified CMM level 2+?
(or did they spend effort&money in getting better rather than getting CMM?)


In other words: does striving for CMM level 2+ imply a significantly larger
probability that the company will become a (really) high quality company,
compared to companies that strive for high quality without bothering about
CMM?

If we would invest in getting highly skilled people, offering a working
environment that is attractive, challenging and encouraging, do what's
necessary to keep them happy and motivated to stay with the company, no
better place to be... If we would make the company so attractive that
everyone would love to come and work there...

... then the company can be selective on who they will hire, taking only the
best of the best, and be more succesfull than their competitors. Would that
perhaps be more profitable than CMM level 2+?


Does CMM stimulate mediocracy by encouraging process definitions that can be
applied to any (dumb) employee with the minimum required skills, rather than
stimulate excellence?


I don't say it is, I just wonder how you thing about it...


Frank.

P.S.
Did I post in the correct newsgroup? If not, please correct me.

Bill M.

unread,
Feb 26, 2001, 12:00:14 AM2/26/01
to
Frank,

You raise a number of issues. I'll start by saying that a high caliber team
is likely to see the largest benefits from working through the CMM.
However, really weak teams are likely to degrade from CMM because weak
performers develop lousy processes. They develop very beaurocratic
processes, and they usually miss the essence of the KPA. The higher the
caliber of people on the team, the more likely that you will have a better
experience ie a better process.

There seems to be the opinion in your post suggesting that all that is
required for good software development is really good people. That's a myth
espoused by many professionals in this business. I've worked in companies
with some highly talented people without any care for process, and the team
navigated from project to project like a rudderless ship traveling the seas
with some of the worst quality that I've ever experienced. I've actually
seen less talented teams produce better work than this team because they had
a good process.

I would say for the most part, though, that most teams fail at CMM, or any
process improvement program for that matter. The number one reason I would
give is that most teams/people are not committed to excellence and the hard
work required to achieve it. Find me a team of people committed to
excellence, and you will find a team working hard, not taking any shortcuts,
and with a defined process. And if they're developing software, they likely
used CMM as the model for their processes. A team committed to excellence
learns from the experiences of their peers, colleagues, and research
conducted by others.

Excellence is an attitude beyond being highly skilled and proficient in your
line of work. Unfortunately, I haven't met too many people in this business
who are willing to pay the price for excellence. Most in this business
believe excellence means putting in an 80 hour work week when in my opinion
it means working smarter and more efficiently.

/Bill

"Frank Sch." <fr...@eindhoven.mailmij.nl> wrote in message
news:aw9m6.50156$MH6.5...@nlnews00.chello.com...

Patrick OToole

unread,
Feb 26, 2001, 11:56:47 AM2/26/01
to

Frank,

I agree that an organization should hire the best and brightest and give
them a wonderful working environment and fill their days with technical
challenges that motivates them to produce high quality results. The CMM
doesn't dispute these things, it just indicates that producing high-quality
products has a process component as well.

Whenever I hear someone questioning the validity of the CMM, I always have
to ask, "What Level 2 process areas are you willing to do without?" Should
you NOT manage your requirements? Should you NOT plan and track your
projects? Should you NOT manage your configurations? Should you NOT verify
that the processes that lead to the highest quality results in the shortest
amount of time are actually being followed?

CMM Level 2 focuses on project management and stabilizes the project
environment such that the technical folks have a fighting chance of doing
their jobs in a professional manner. Although I'll admit that the Wild Wild
West of software development can be fun, it can also be very trying at times
and cannot be relied on to produce quality results in a repeatable manner.


"Frank Sch." <fr...@eindhoven.mailmij.nl> wrote in message
news:aw9m6.50156$MH6.5...@nlnews00.chello.com...

Frank Sch.

unread,
Feb 26, 2001, 10:16:30 AM2/26/01
to
No, I am not implying that you ONLY need good people. But I do think that
you can't reach excellence if you don't have good people, nor can you reach
CMM level 2+ if you don't have good people.


I have the impression that a lot of companies assume they can reach
excellence (or at least something near to it) by applying CMM, even with a
shortage of good people. Or worse, they have good people for their business
goals but they assume those are the right people to implement CMM too.

Frank.


Bill M.

unread,
Feb 27, 2001, 12:11:42 AM2/27/01
to

"Frank Sch." <fr...@eindhoven.mailmij.nl> wrote in message
news:irum6.56154$MH6.6...@nlnews00.chello.com...

> No, I am not implying that you ONLY need good people. But I do think that
> you can't reach excellence if you don't have good people, nor can you
reach
> CMM level 2+ if you don't have good people.
Agree.

> I have the impression that a lot of companies assume they can reach
> excellence (or at least something near to it) by applying CMM, even with a
> shortage of good people. Or worse, they have good people for their
business
> goals but they assume those are the right people to implement CMM too.

Good points. If you have the right people leading the CMM effort, you can
take most teams and make them much better. I think that's the hope of most
organizations that embark on this process. It is risky. I've seen some
teams use the process as an excuse for not delivering and a way to lesson
their responsibility. So in the end, it finally comes down to having good
people and most importantly having highly competent leaders as they will
rein in the people looking to use the process as an excuse.

>
> Frank.
>
>


Nigel Tzeng

unread,
Feb 27, 2001, 5:54:07 PM2/27/01
to

"Patrick OToole" <pact....@worldnet.att.net> wrote in message
news:jVvm6.4959$gc7.3...@bgtnsc07-news.ops.worldnet.att.net...

>
> Whenever I hear someone questioning the validity of the CMM, I always have
> to ask, "What Level 2 process areas are you willing to do without?"
Should
> you NOT manage your requirements? Should you NOT plan and track your
> projects? Should you NOT manage your configurations? Should you NOT
verify
> that the processes that lead to the highest quality results in the
shortest
> amount of time are actually being followed?

Perhaps those aren't the right questions. It (almost) goes without saying
that being
able to handle (most) level 2+ KPAs is important to success because the
source
of these KPAs are successful projects and experience. Perhaps the right
questions
are:

Is there an improvement process that is more cost effective than CMM?
Can I believe the fantastic ROI claims of CMM proponents?
Does CMM really provide silver-bullet like performance increases?
What is the failure rate of CMM initiatives? Funny how SEI doesn't track
that.
What could I be spending my money on other than CMM training and
certification?
Is SW-CMM really a competitive advantage outside the arena where CMM
maturity is a contractural requirement?
What kind of shop is more productive? CMM? Extreme Programming? Design By
Contract? Sure, I can do CMM and something else, but who has the time and
money to learn and implement two new processes? Time and money are finite
resources so is CMM automatically the most "valid" choice?

What about GQM? Different school (University of Maryland), different guru
(Basilli), different process improvement paradigm. Had DoD awarded the
contract to Maryland instead of CMU, we'd be questioning the "validity" of
GQM and Software Cleanroom (well okay, everyone questions cleanroom anyway).

It's been a while but back when I was looking into this, I noticed that the
performance
gain of CMM is similar to that claimed by proponents of Fagan inspections.
Interesting isn't it? Interesting too is that both inspections and CMM (or
at least SEI
consultants) were (heavily?) used on the classic software disaster example:
FAA.

Nor was IBM Federal Systems Division a stranger to SPI and CMM (hmm...were
they Loral FSD by then?) so what happened?

I think that questioning the "validity" of CMM is not entirely without
merit. That it
works and works well for other shops is great. But is that experience valid
in my
domain with my engineers?

Nigel


Bill M.

unread,
Feb 27, 2001, 10:09:24 PM2/27/01
to
Nigel,

From reading your reply, I get the sense that you wouldn't be comfortable
with any sort of software development process model, but you do ask some
good questions that should be answered. However, depending on your biases,
the answers may or may not be well received, and similarly, depending on the
biases of the person answering, you'll get 2 different answers.

As for the fantastic claims, there is much hyperbole by the promoters of all
new technologies or old ones that have yet to be widely accepted; similarly
the detractors of thes technologies create the same confusion on the
opposite end of the spectrum. Having implemented much of the essence of CMM
in an organization that was clearly operating in chaos, I can say from
experience that the returns are great, but those returns would be there for
any process improvement innitiative of any value. Further, those returns
would be achievable by any veteran software development manager that was
worth his weight. Why CMM? Because I have experience with it and it is a
good model.

There is probably a high failure rate with CMM, but that has less to do with
CMM than the people developing the program. If I gave 10 software
development teams the specifications for building a challenging product,
most would fail; maybe one solution would be excellent, and the rest would
range from meets the needs to it really sucks. Did the teams that fail or
developed a lousy product do so because the specification was inadequate?
maybe, or maybe they failed because they just weren't a good team. By
analogy I think CMM is a good model, but most teams that try to implement it
fail because they just aren't good.

As for are there competing paradigms that are better, I would say possibly.
It's hard to know because who gets a chance to understand and implement all
of them. Remeber, though, that CMM is a model not an implementation, and
it's quite possible that Extreme programing could be an instance of CMM.
If Extreme Programming meets all the level 2 KPA objectives, it defines a
level to process. That's the beauty of CMM

Process improvement is hard stuff. I wouldn't expect any of the alternative
processes to be easy to implement, and from the little I've read about some
of the ones you mention, I don't see them as being all too practical. My
final advice would be that for anyone looking for a silver bullet, you
better keep doing what you've been doing because you will fail trying to
implement any process improvement program -- it's hard work and it takes
talented, mature professionals to be successful.

To answer your last question, what makes CMM possibly the right solution for
your domain is that it does not proscribe a process, that's for the team
with it's culture and talent to develop.

/Bill

"Nigel Tzeng" <ntz...@corvis.com> wrote in message
news:97hb68$o8laa$1...@ID-75605.news.dfncis.de...

Frank Niessink

unread,
Feb 28, 2001, 5:48:42 AM2/28/01
to
Bill M. <Bi...@hello.com> wrote:
>
> Process improvement is hard stuff. I wouldn't expect any of the alternative
> processes to be easy to implement, and from the little I've read about some
> of the ones you mention, I don't see them as being all too practical.

Basically, two categories of approaches to process improvement can be
distinguished:

- External reference based improvement (also called top-down, maturity-based,
or assessment-based improvement), meaning that the organization uses
an external framework as a reference to compare itself with and use as
the basis for improvement. Examples of such frameworks are the Software
CMM, ISO 15504 (SPICE), Bootstrap, Trillium, ISO 9000, EFQM, etc.
An important assumption when using such models is that they are
applicable to your situation and that the guidance they provide is 'good'.

- Internal reference based improvement (also called bottom-up,
measurement-based improvement) where internal references are used as
yardstick. In this case organizational problems or goals are the starting
point, information is gathered to analyze the problem or decide on the way
to reach the goal, changes are implemented and tracked to see whether the
change is indeed an improvement. Examples of methdology in this category are
the Goal/Question/Metric paradigm (and the enclosing Quality Improvement
Paradigm) of Basili et al, and other measurement (program) based approaches.

My guess (based on my own experience and literature) is that both approaches
are about equally difficult to accomplish, mainly because of the fact that,
in the end, if the assessments are done and the processes are described and
the metrics are derived, you *still* have to change the organization to bring
about the improvement... and that is hard. But it is not simply a case of
well-meaning process improvement gurus versus grumpy change avoiding
practitioners: change gets resisted for good reasons...

BTW, I wouldn't say the measurement-based approaches are less practical,
they too have their merits. And if their implementation succeeds you can
sometimes get surprising information with simple metrics.

Cheers, Frank
--
That evening it was dark early, which was normal for the time of year. It was
cold and windy, which was normal. It started to rain, which was particularly
normal. A spacecraft landed, which was not.
-- Douglas Adams, 'So long, and thanks for all the fish'

Nigel Tzeng

unread,
Feb 28, 2001, 2:34:08 PM2/28/01
to

"Bill M." <Bi...@hello.com> wrote in message
news:EZZm6.37181$Vj5.5...@news02.optonline.net...

> Nigel,
>
> From reading your reply, I get the sense that you wouldn't be comfortable
> with any sort of software development process model, but you do ask some

Not exactly. CMM is not a software development process but a software
development process improvement process model. We always have a software
development process model even if it happens to be the code and fix model.

Likewise, we always need a good handle on the major KPAs or we face
shooting ourselves in the foot. That's not really at issue...for me
anyways.

The question is whether implementing a more formal process improvement
methodology (CMM) is one-size-fits all and more cost effective than more
informal methods or other "formal" methods like GQM. Smaller shops may
require a different software development process improvement model than
the Raytheons of the world...though there has been some interesting case
studies for smaller organizations that do CMM.

When someone questions the "validity" of CMM, I would think that would
be the question rather than "should we do requirements management".

> good questions that should be answered. However, depending on your
biases,
> the answers may or may not be well received, and similarly, depending on
the
> biases of the person answering, you'll get 2 different answers.
>
> As for the fantastic claims, there is much hyperbole by the promoters of
all
> new technologies or old ones that have yet to be widely accepted;
similarly
> the detractors of thes technologies create the same confusion on the
> opposite end of the spectrum. Having implemented much of the essence of
CMM
> in an organization that was clearly operating in chaos, I can say from
> experience that the returns are great, but those returns would be there
for
> any process improvement innitiative of any value. Further, those returns
> would be achievable by any veteran software development manager that was
> worth his weight. Why CMM? Because I have experience with it and it is a
> good model.

That's a perfectly good answer. CMM works well for you and many others. If
you were leading the process improvement initiative, I'd recommend CMM
if for no other reason that you've done it before, were successful and hey,
you're
doing the work and its your preference...I'm certainly not going to insist
on
something else that I read in some magazine somewhere.

> There is probably a high failure rate with CMM, but that has less to do
with
> CMM than the people developing the program. If I gave 10 software
> development teams the specifications for building a challenging product,
> most would fail; maybe one solution would be excellent, and the rest would
> range from meets the needs to it really sucks. Did the teams that fail or
> developed a lousy product do so because the specification was inadequate?
> maybe, or maybe they failed because they just weren't a good team. By
> analogy I think CMM is a good model, but most teams that try to implement
it
> fail because they just aren't good.

Now this is an interesting observation. So CMM is as dependent on the
people
as say, Good Enough Software is dependent on the quality of its people?
Hmmm.
So you might say that CMM initiatives succeed or fail based on the
effectiveness
of the process "heros" that were assigned to it?

Okay, its obvious that I'm deliberately taking that paragraph in a direction
that
most folks at SEI would disagree with ...but it is amusing that a defense of
failed
CMM initiatives is the same one used for failed software projects.

> As for are there competing paradigms that are better, I would say
possibly.
> It's hard to know because who gets a chance to understand and implement
all
> of them. Remeber, though, that CMM is a model not an implementation, and
> it's quite possible that Extreme programing could be an instance of CMM.
> If Extreme Programming meets all the level 2 KPA objectives, it defines a
> level to process. That's the beauty of CMM

I suspect you can make it fit, so long as you had a good lead assessor who
made
allowances for difference in approach. For example, I believe that
programming
in pairs replaces peer reviews but there certainly is no equivalent
documentation.

> To answer your last question, what makes CMM possibly the right solution
for
> your domain is that it does not proscribe a process, that's for the team
> with it's culture and talent to develop.
>
> /Bill

Maybe. While it doesn't proscribe a development process, it certainly
proscribes
an improvement process, if in no other way than the maturity level
structure. Now,
most (all) CMM experts will tell you that nothing in CMM insists that you do
all level
2 KPA before level 3 KPAs but that's somewhat implied. Do as much as you
like in
Level 3+ but miss any Level 2 KPA in some manner and you're back to Level 1.

But the real questions is: If I have X dollars, do I get more from spending
it on hiring
better people, improving benefits and working environment and decreasing
turnover
or do I get more from spending it on CMM?

Generally, that's my viewpoint...if you hire and keep good people, they
gravitate
toward processes that are better and even more, have the desire to improve
their
processes. Getting a high maturity in Peopleware (*) seems more important
than
in SW-CMM in the proverbial level 0 organization.

Nigel

(*) I prefer DeMarco and Lister's pearls of wisdom over the People-CMM
model which seems more geared toward configuration management of people as
interchangeable cogs with some lip service tacked on for care and feeding of
these
cogs. If any assessment of an organization with cubicles rank above Level
1, the
model is broken. Likewise, any organization with large turnover and/or
consistenly
long hours should get a level 1 designation.


Ed Weller

unread,
Feb 28, 2001, 5:08:26 PM2/28/01
to

Regarding CMM and XP, Mark Paulk did a nice presentation at the Applications of
Software Measurement conference on how XP satisfies (or not) the various level 2
and 3 KPAs. A rather interesting view given the wide coverage XP provided.

Bill M.

unread,
Feb 28, 2001, 7:53:27 PM2/28/01
to
> BTW, I wouldn't say the measurement-based approaches are less practical,
> they too have their merits. And if their implementation succeeds you can
> sometimes get surprising information with simple metrics.

Whatever gave you the impression that I find measurement-based approaches as
less practical? I use many simple metrics, and I find them quite powerful.

/Bill

"Frank Niessink" <nies...@serc.nl> wrote in message
news:97il2a$jnm$1...@newshost.accu.uu.nl...

Bill M.

unread,
Feb 28, 2001, 8:43:24 PM2/28/01
to
>
> When someone questions the "validity" of CMM, I would think that would
> be the question rather than "should we do requirements management".
>

I see your point. It's not readily obvious when I first read it, but your
explanation clarifies it for me. Sure CMM isn't perfect, and it is hard to
understand what the goals are for some of the KPAs. Further, there is no
road map for implementation of a process improvement program. That is left
to the teams doing the process improvement. So most teams start from 1 and
work to 5. Sure CMM needs some work, but I would argue that they've nearly
exhaustively defined the issues, and they may even have gone overboard.
That's why the quality of the people leading the process improvement program
is so important.


> Now this is an interesting observation. So CMM is as dependent on the
people
> as say, Good Enough Software is dependent on the quality of its people?
> Hmmm. So you might say that CMM initiatives succeed or fail based on the
> effectiveness of the process "heros" that were assigned to it?
>
> Okay, its obvious that I'm deliberately taking that paragraph in a
direction
> that most folks at SEI would disagree with ...but it is amusing that a
defense of
> failed CMM initiatives is the same one used for failed software projects.
>

You seem suprised, but would you really expect anything different? Give me
10 C programmers and the quality of their work will vary. Why should that
be any different for implementing process? Actually, I would argue that
since changing an organization is so difficult, you need really top notch
people to make it happen successfully.

>
> Maybe. While it doesn't proscribe a development process, it certainly
> proscribes an improvement process, if in no other way than the maturity
level
> structure.

I would suggest you have this slightly incorrect. It defines the activities
and the measures of a successful process, it is up to the team to define the
improvement process. Two teams implementing CMM will have vastly different
improvement processes. Maybe that's a reason for some of the failures.

>
> But the real questions is: If I have X dollars, do I get more from
spending
> it on hiring better people, improving benefits and working environment and
decreasing
> turnover or do I get more from spending it on CMM?

My experience, and that's all I can speak for, is that most organizations
would see larger improvements spending their buck on process improvement
since it normally is the weakest part of many organizations. That's where
all the inefficiencies typically lie. Once you have a large enough team,
communication and control break down. Process facilitates communication and
control, and makes everyone accountable rather than one person chosing to
take responsibility ie little gets left to chance. I'm always suprised how
some very bright engineers fail to see the benefits of good process.

> 1, the model is broken. Likewise, any organization with large turnover
and/or
> consistenly long hours should get a level 1 designation.
>

Definitely a sign of an organization working in chaos and by the seat of the
pants. I like that measure.

Frank Niessink

unread,
Mar 1, 2001, 2:16:37 AM3/1/01
to
Bill M. <Bi...@hello.com> wrote:
>
> Whatever gave you the impression that I find measurement-based approaches as
> less practical? I use many simple metrics, and I find them quite powerful.

Well, you said:

>>> Process improvement is hard stuff. I wouldn't expect any of the
>>> alternative processes to be easy to implement, and from the little I've
>>> read about some of the ones you mention, I don't see them as being all too
>>> practical.

And 'the ones you mention' points back to among other things GQM in a
previous post. But maybe I misread what you meant, sorry about that then.

Guess we are in agreement then :-)

Cheers, Frank
--
"Hi," it said, "I've just been created. I'm completely new to the Universe in
all respects. Is there anything you can tell me?" "Phew," said Ford, a little
nonplussed, "I can tell you where some bars are, I guess."

Nigel Tzeng

unread,
Mar 1, 2001, 10:34:11 AM3/1/01
to

"Bill M." <Bi...@hello.com> wrote in message
news:0Phn6.42122$Vj5.6...@news02.optonline.net...

> You seem suprised, but would you really expect anything different? Give
me
> 10 C programmers and the quality of their work will vary. Why should that
> be any different for implementing process? Actually, I would argue that
> since changing an organization is so difficult, you need really top notch
> people to make it happen successfully.

Not surprised, just mildly amused that we've simply moved the problem up
one level and that good people are always needed. There was an argument
(not by SEI folks mind you) way back when that CMM maturity would allow
average programmers outperform "elite" programmers on large projects.

So before, we depended on our software heroes to save our projects (that
is the level 1 assumption anyway) now we depend on our process heroes to
save
our change initiatives.

The question is change management (process improvement) in a large
organization
any more or less tractable than large software projects. This isn't to say
that
we shouldn't TRY to change large software organizations but we can probably
expect that every so often we suffer from "process improvement disaster" as
opposed to "software disaster".

And you do need to factor in the probability of failure to your ROI
estimation.

> My experience, and that's all I can speak for, is that most organizations
> would see larger improvements spending their buck on process improvement
> since it normally is the weakest part of many organizations.

I dunno...it certainly depends on the organization. IIRC the rule of thumb
is that the average programmer stays about a 15-36 months...call it 24.
Estimated
startup costs (headhunter fee, time spent by other employees to get the new
hire up
to speed, time spent by employee reaching full productivity, etc) for a new
hire
is 3-5 months or about 15-20% of the value of the employee.

So if you have high turnover, fixing that should net you some nice gains.
Now,
there does appear to be some correlation between high CMM maturity level and
reduced turnover...but that's likely a result of the reduction in death
marches within
high maturity organizations.

There appeared to be some correlation between productivity and quiet
workspaces
too. Whether good programmers preferred good working environments or good
working environments produced programmers with more think time is debatable
but in DeMarco and Lister's coding war games those folks with quiet
workspaces
(generally offices) had fewer defects and higher productivity.

So, I might be tempted to address these two issues first...any subsequent
process
change expenditures are likely to have more advantageous results since the
folks
that build the processes are around longer and have more think time to
design and
implement it.

Nigel


Bill M.

unread,
Mar 1, 2001, 11:31:39 PM3/1/01
to

> one level and that good people are always needed. There was an argument
> (not by SEI folks mind you) way back when that CMM maturity would allow
> average programmers outperform "elite" programmers on large projects.
>
I find the over exaggeration and hyperbole disturbing when new technologies
are introduced in this field. I recall working on a Java project a few
years back, and the buzzword was that Java was more productive than C++.
Usually the advocates of such fiction never have any data to back up their
gross exaggerations. Further, they rarely have hands on experience.
Fortunately, on this particular project I had both C++ development and Java
development with experienced engineers in both technologies. The
productivity of the C++ programmers was twice that of the Java programmers.
Most of the reasons had to do with the Java tools being so immature and the
VMs being so buggy. My guess is that once Java matures engineers would be
equally productive on C++ vs Java.

As for process, I would argue if a team has a good SE process than the
engineering team has the potential to be more productive than the sum of its
parts -- like in sports teams with average players outperforming teams with
superstars. The same is possible with an engineering team. Process is
about focusing on team development. In the end, we shouldn't emphasize star
players at the expense of team development or visa versa. They're both
equally important, but depending on the organization, I could see one being
more important than the other for an instance in time.


Ed Weller

unread,
Mar 2, 2001, 10:49:47 AM3/2/01
to
Bill has it right. What I see happening is that a proper use of the CMM, or any
other (good) model, technology, tool, etc., will allow an organization to
improve its capability. Unless you can identify and replace the "bottom xx%" and
replace them with "better" people (whether that is smarter, more knowledge,
etc.) and do it without losing valuable core competencies/product knowledge, you
are pretty well stuck with the people you have. The job market isn't flexible
enough to make wholesale changes in your workforce.

The question is, with my current staff, can I get better results? Using the CMM
as a guide, I have significantly improved quality and productivity of an
organization (quality 5-10x, 2x reduction in test cycles - see
http://www.asq.org/pub/sqp/past/vol3_issue1/weller.html for one example).

Note I said using the CMM as a guide. I am not a slave to achieving CMM levels.
I did/do use the CMM and CMM assessments to evaluate organizations' strengths
and weaknesses. It is a useful tool, as long as we keep in mind that any tool
can be misused.
Ed Weller

Stephanie S

unread,
Mar 13, 2001, 9:35:18 AM3/13/01
to
<SNIP>


> Find me a team of people committed to
> excellence, and you will find a team working hard, not taking any
shortcuts,
> and with a defined process.

And if there is a problem with the process they fix the process rather than
dropping it like a hot rock.

> And if they're developing software, they likely
> used CMM as the model for their processes. A team committed to excellence
> learns from the experiences of their peers, colleagues, and research
> conducted by others.
>
> Excellence is an attitude beyond being highly skilled and proficient in
your
> line of work. Unfortunately, I haven't met too many people in this
business
> who are willing to pay the price for excellence. Most in this business
> believe excellence means putting in an 80 hour work week when in my
opinion
> it means working smarter and more efficiently.

Can I get my boss (and the rest of my team) to read your posts??!!??

Stephanie S

unread,
Mar 13, 2001, 9:35:39 AM3/13/01
to
Newbie ignorant questions... what's CMM?

Thanks

S


"Frank Sch." <fr...@eindhoven.mailmij.nl> wrote in message
news:aw9m6.50156$MH6.5...@nlnews00.chello.com...

Frank Sch.

unread,
Mar 13, 2001, 4:35:03 PM3/13/01
to
CMM is an acronym of Capability Maturity Model.

It is a model that defines the maturity of a software organisation towards
their capability of performing software projects. The model is divided into
5 levels:

Level 1: default if the organisation is not another level, varying from
total chaos to heroic efforts. At this level the organisation highly depends
on the (incidental) availability of very good people to be succesfull.

Level 2: a repeatable process. The organisation is able to perform a similar
project, with similar technology, similar requirements, similar people in a
similar way. Some people are joking about it that if you are able to make a
mess of it repeatedly, you are at level 2.

Level 3: a defined process. Rather than having each project being able to
repeat the same thing over and over again, at this level there is an
particular way of working defined for the organisation, which is used within
projects.

Level 4: an managed process (*). Not only does the organisation define the
processes, also process improvement in place. Lessons learned from
performing projects are put back into the organisation and used to perform
the next project a little bit better.

Level 5: a optimised process (*). Now the organisation is not only a
self-learning organisation, also it is able to predict the impact of changes
of technology, organisation, processes, etc. before it is deployed in the
projects. It is accurately known which parameters influence the performance
of the organisation, and how.


At each levels (except level 1), a number of Key Process Areas are defined
which determine what process areas have to be in place. For example, with
level 2 you have to have Requirement management, Project planning, Project
Tracking & Oversight, Subcontract management, Configuration management and
Quality Assurance in place. For each KPA it is defined what yuo actually
have to have in place, involving issues focussing on commitment, ability to
perform, activities, verification and measurements.

If you want to know more about CMM, have a look at the SOftware Engineering
Institurre (SEI) or read some books about it.

Frank.

Maybe I exchanged the names for Level 4 and 5.

Stephanie S <st...@vsac.org> schreef in berichtnieuws
tcqr6.673$%s3.3...@nntp1.onemain.com...

James Kanze

unread,
Mar 18, 2001, 3:41:02 PM3/18/01
to
"Nigel Tzeng" <ntz...@corvis.com> writes:

|> "Bill M." <Bi...@hello.com> wrote in message
|> news:0Phn6.42122$Vj5.6...@news02.optonline.net...

|> > You seem suprised, but would you really expect anything different?
|> > Give me 10 C programmers and the quality of their work will vary.
|> > Why should that be any different for implementing process?
|> > Actually, I would argue that since changing an organization is so
|> > difficult, you need really top notch people to make it happen
|> > successfully.

|> Not surprised, just mildly amused that we've simply moved the
|> problem up one level and that good people are always needed. There
|> was an argument (not by SEI folks mind you) way back when that CMM
|> maturity would allow average programmers outperform "elite"
|> programmers on large projects.

But it requires "elite" managers:-).

Seriously, without a process, even the best programmers are not going to
be very productive, so using a process (not necessarily SEI) will result
in more productivity. Where I've seen the important gains, however: on
any project, there are large parts which don't require a guru level.
With a well run process, those parts are identified and given to the
non-gurus. The result is that the guru is free to work on the parts
that really need his expertise. (A second result is that the guru is
generally much happier not having to waste most of his time with simple
grunting.)

--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

0 new messages