Saturday, May 31, 2008

What is a Project?

When starting down the road to process improvement and implementing the CMMI, one of the critical items that must be clearly defined up front is a project. Maturity Level 2 is all about stabilizing the project and developing realistic and accurate estimation models. And the problem many organizations encounter is appropriately defining a project so they are not overburdened by required processes.

The Project Management Institute (PMI) defines project as a temporary endeavor undertaken to create a unique product or service. And the CMMI defines project as a managed set of interrelated resources which delivers one or more products to a customer or end user. Both definitions are correct and complement each other. Along with these defintions, projects have the following characteristics:
  • goals or objectives
  • starting date and ending date
  • identified deliverables
  • identified resources and budget
  • schedules and milestones
  • plan (who, what, when, how)
  • project manager
  • sponsor
  • stakeholders (other affected groups)

There are at least three basic project types:

  • new development
  • maintenance (bug fixes and enhancements)
  • operations

Organizations with new development projects usually don't have a problem with defining a project. However, when there is maintenance, many times the organization starts by defining an individual product change as a project, and many times a single change (especially for bug fixes) does not have all of the project attributes listed above. Therefore it is extremely important for the process implementation team to sit down for several hours to a day with a CMMI expert and talk through how the organization has organized its work in order to arrive at a definition of project for the organization. And there could be several different project types.

Another interesting situtation arises when the organization is responsible for operating something (power plant, control center, Space Shuttle, etc.) for a customer. Depending on the type of operations needed, the organization may be performing systems engineering tasks and activities as well as some software engineering tasks and activities. However, when you examine an individual systems engineering or software engineering task or activity, it may not satisfy the project attributes listed above and it may not cover the entire product lifecycle. These tasks and activities could be considered as sub-projects. So, just like in the maintenance environment, the organization should meet with a CMMI expert to talk through how work is performed within the organization to determine the proper definition of a project so the CMMI can be correctly applied.

2 comments:

Anonymous said...

Hi Henry,
Sorry, but I miss how consulting a CMMI expert is going to help organizations execute projects any better?

If you check out Max Wideman's highly regarded Glossary of Project Management Terms, http://www.maxwideman.com/pmglossary/index.htm you will find something on the order of 20 definitions for "project" and close to the same number for "project manager".

Research Bill Duncan, Ishi Ishikura and I did on behalf of the Global Alliance for Project Performance Standards (GAPPS) www.globalpmstanards.org identified 4 categories for "Program".

IMPO, I think looking to capability maturity problems is looking at the trees and missing the forest.

I know of several of my clients who ostensibly score "high" on capability maturity models yet still fail miserably to deliver projects on time, within budget substantially in conformance to specifications, and the problems I see come from problems much more fundamental, like not being truly a project centric based organizations, not having/using activity based costing systems or perhaps the most damaging, expecting people to "serve two masters" by working in a matrixed environment.

Project management as it is being practiced today is akin to medicine of the 17th century. I think the model or methodology we are using is totally wrong,and the tools we are using (i.e. MS Project et al) which don't allow for feedback loops, are a major part of the problem. Wrong tool for the job.

I would urge you to reflect on what is happening in the world of project management and get beyond the hype and start to look at the real root causes.

BR,
Dr. PDG, Jakarta

Henry Schneider said...

Hi Paul,
I am sorry, but you missed the point of my blog. In order to correctly implement the CMMI, the organization must properly define a project in their context. This message is the whole point of my blog entry. Organizations that incorrectly define a project experience challenges with implementing the model.

Now, most organizations that have implemented the CMMI and reached Maturity Levels 3+ have vastly improved their ability to estimate, manage, and deliver their projects. However, those organizations that have rapidly implemented the CMMI without building the foundation of basic project management practices inherent in Maturity Level 2, mostly what has happened in India over the past several years, have not achieved these results. That is why the Software Engineering Insitute (SEI) has made the process more rigorous.

I refer you to the SEI's web site www.sei.sme.edu for more information and technical reports about improvements in project management over the past 20 years that have resulted from using Maturity Models.