Does a process like CMMI really helps a project

Question

What do you think is the advantage of processes like CMMI in a project. When I go into a CMMI meeting I feel like I wasted a couple of hours because I don't see any value in filling all those project related documents that I know will never be reviewed again by anyone. I have updated hundreds of CMMI related documents in the last 2 years but never went back to check anything.

Having said that, I am not against preparing project related documents. When I start a project of my own(not company related), I prepare the relevant documents as required (sort of SRS, project related details etc). A issue tracking system(like unfuddle) is what I use the most along with a document management system (Google Docs). I use the Issue Tracking System to manage all the requirements, issues and new features and it works out very well for me. Google Docs is used to keep project related information along with architecture diagrams, demo videos etc.

I have not done (or seen in my company) even a single project that was effectively tracked using the Project Plan. It looks so unrealistic to specify time for each task and then track it on a daily basis.

Has anyone done effective project management using tools available in CMMI?

Answer 1

A quality management method like CMMI is time consuming but when you implement it well I'm convinced that it is an effective program management method.

Actually you're naming the issues in your situations. CMMI is somehow implemented but not all teammember seem to live by it. (Your reviewing example).

And then there is always the most important question, does the project really need CMMI? When working in larger teams, bigger projects I can recommend it. But most important thing for making it succesful and not a pain in the ass is to motivate all teammembers to activly work by the method. Store files at locations which are agreed (CM), review the way you agreed, use your planning as a planning, not as a must-have document.

And another thing I'm curious about, at which level (1-5) of CMMI do have to operate? I have experience at level 2.

Answer 2

Project management must be done a la carte, depending on the team and the project / product. You can't just pick a process, blindly apply it and hope for the best.

Going through the motions of any existing process, without making sure it fits the needs of the project team, and without making sure it's providing concrete benefits is just overhead. You end up with the worst of both worlds - the overhead of a process, and the effectiveness of no process.

Answer 3

CMMI should not be about producing lots of documents. A team following a highly agile process such as Scrum or Extreme Programming can rate highly in the CMMI scale without producing large numbers of documents. Google for agile CMMI for lots of resources and articles on the subject.

IMHO CMMI should be about process improvement, not about creating lots of paperwork or mandating a specific process. However if done badly it can become a barrier to process improvement instead. Once a process is documented it becomes regarded as "the official way to do things" and deviation from the documented process is frowned on and punished, but rather it should be regarded as a starting point, e.g. "this is how we do things now, so what can we change to become more effective?".

Answer 4

The benefits you can expect from using CMMI include the following:

1) Your organization's activities are explicitly linked to your business objectives. 2) Your visibility into the organization's activities is increased to help you ensure that your product or service meets the customer's expectations. 3) You learn from new areas of best practice (e.g., measurement, risk)

For some of the tools on CMMI, refer to the following link:

http://www.sei.cmu.edu/cmmi/tools/index.cfm

Answer 5

I'll hazard a guess: Someone said your company had to be CMMI level X to win a contract. Your boss went and found an appraiser or contractor willing to train you or get you to level X. At this point, no one in your company really knew what Level X entailed or what it meant - NOR DID THEY CARE. Actually, they were probably willing to incur a certain amount of operational pain and inefficiency in order to win a contract.

So they hired someone who they thought would be easy to work with, available, and get them to level X quickly. They then likely took an approach commonly known as "pathological box checking" - you can google it. The result of that was a bunch of process documents and templates. Then an appraiser came in, viewed the documents as some sort of proof that a process occurred and walked away, and your company got it's stamp.

The number of failures in systems thinking here is amazing; there's plenty of blame to spread around.

It is especially sad that the system of forces are set up to make this a common outcome.

So, in theory, the advantage of CMMI is that it improves your processes, for some definition of improve, according to a specific value system that values defined, repeatable, documented, low-variation, 'measured' process.

In practice, the advantage is that getting the level means you get access to a customer for whom getting the certification is important.

Good luck with that. Let us know how it goes.

Answer 6

My suggestion is to go through the current set of documents and evaluate each from the project stakeholders’ perspective. One way to go about it is to create a table, with document types as column and stakeholders as row headings, put document value relative to a stakeholder on the intersection of the two along with some notes, i.e. High, Low, None. See if any of the documents don’t provide much value to anyone, if any have to be altered to be more pertinent, if some of the information can be maintained with lower administrative burden.

As a software development analogy CMMi can be thought of as a set if re-usable libraries, software framework, operating system and monitoring tools. Creating any of these from scratch as part of building a web applications like, let’s say, Stack Overflow would feel like a lot of burden.

But having .NET framework, AJAX libraries and Windows Server out of the box (meaning someone else somewhere would take care of developing and maintaining them), all of this goodness available for your projects on the cheap pays off in spades and let’s you concentrate on building functionality that matters to your users.

I believe that CMMi implementation (or any improvement made as part of it), should serve your projects and not the other way around. It has to be convenient, out of the box, to the point when it’s possible just to slot a new project into the management system and make use of existing infrastructure without having to carry too much burden, when the project benefits from the day zero even without the detailed understanding of the management system innards, and certainly without excessive tinkering and maintenance.

Answer 7

The answer given by Matthew Heusser is very good, but let me speak from a different perspective.

CMM**I** helps you find out bottlenecks and processes that can be improved - leading to better productivity and thoroughput in the next cycle. If you are more concerned with the current delivery, Agile methods, from my experience, have been always more efficient, but highly coupled with the team that worked on that project.

However, where it shines is when it was implemented in a project that failed for some reason

If you implemented the process correctly - you then can find out what that reason was, and make sure it's mitigated ( does not happen again ) the next time.

Given enough exposure to a domain, you then have a set of processes using which you can be confident that your chances of failure is minimized.

That's it!

Answer 8

CMMI can only really have a hope of helping a project (and the organization the project is in) when CMMI is used correctly.

Unfortunately, most organizations (especially in the USA -- it's bad but not as bad abroad) don't use CMMI correctly because what they are after isn't improvement it's marketing.

Because organizations don't see anything they can improve (except top-line sales), they fail to see the way in which to use CMMI so that doing so adds value Ultimately, poor implementations of CMMI boil down to a culture that doesn't value improvement, or doesn't know how to pursue improvement. Similarly, there are organizations who use agile practices in name only, but are not truly agile. Such organizations will have problems with CMMI because if they're not serious about agile, how can they be serious about value or improvement? Show me an organization that believes it has nothing to improve, and I'll show you an empty office in 5 years.

There are some cases where the organization does value improvement, but they don't know what to look for and how to find and hire people (internals, consultants, appraisers, etc.) who can help them use CMMI to add value.

Unfortunately, there are also many organizations who assume there is only one way to use CMMI, or there is only one way to be appraised, or that the SEI is making sure all consultants and/or appraisers think and work the same way.

The bad news is that the SEI is currently not normalizing all the consultants and appraisers, and even more important is that using and appraising CMMI is very context-specific, so there cannot be just one way to use or appraise it. In fact, it's the lack of context that causes so many implementations of CMMI to fail. Another attribute of a culture lacking in a value-oriented disposition is such a failure to account for the organization's context.

Understand CMMI's value-oriented context and put it in a context-sensitive culture that values value, and CMMI does very well.