Project Classification Part Two

This is a follow on discussion to http://ppqc.blogspot.com/2009/04/project-classification.html

I will try to make my point clear here. Let's assume for a moment that an organization has identified project types i.e development and testing. If such an organization has to go for CMMI ML 2, then what should be their approach to further segregate each project type for better process implementation? I would like to look at project duration (start date and end dates) , the SDLC (phases), number of people working on project or effort put on the project.

Is there any other technique or anything else I should look at to categorize each project type into small, medium and large? Because I do not find CMMI publishing any kind of guidelines for segregating projects into small, medium and large. So ideally as you said ..project size... Can we say that to look at project size we need to look at effort required to complete the project and duration of project? So I am looking for other parameters to give the organization better picture of the basis to arrive at small, medium and large projects.

Thank you so much for the clarification.

You seem to be making a distinction between project type and project classification. In my mind project type and project classification are two different terms that mean the same thing: category. As you have discovered, there isn’t any guidance for what is a project type or classification. This categorization is up to the organization to determine for its internal purposes. Project size could be a classification, but is probably not the best one to use. As I have suggested in other posts, application domain, platform, language, methodology, etc. are potentially better categories to use. And the primary reason for labeling projects with a category is to allow the organization to compare like against like. For example, there is not a whole lot of value in comparing a web development project to a mainframe project, or a web development project to a road construction project. You want to compare apples to apples and oranges to oranges, not a mixture.

But I think that the bigger issue here is defining what is a “project” for your organization. A project has a defined start and stop, budget, resources, tasks, schedule, identified deliverables, and typically operates according to a plan. And a project can be composed of other projects. Once you have decided on what a project is for your organization, then it becomes pretty obvious the project types or classifications that make sense for your organization.

Typically I do not find that organizations have separate projects for development and testing. Testing is part of the development lifecycle and typically not treated as a separate project. However, you may have a testing plan, testing resources, funds, and a testing schedule. So testing could be a sub-project of the main development project. Therefore, I would not normally expect that projects would be categorized as development or testing. However, I have seen projects categorized as development or maintenance projects. Once you have decided on the primary project categories for your organization, then it might make sense to look at size (small, medium, large) within a specific category to further refine your definitions and comparisons.

Project Classification

I heard from a colleague that project classification needs to be done to be compliant to the Project planning processes. Which Project Planning Specific Practice (SP) refers to project classification?

I am not sure what you mean by project classification. Do you mean application domain? Or project size? Or something else entirely?

My best advice to you is not to listen to colleagues who may not be CMMI experts, but instead work with a CMMI consultant or SEI-certified Lead Appraiser. They will provide you with the best information and CMMI interpretations.

The CMMI does not state that you must classify projects for Project Planning (PP). That is why you are having difficulty determining the applicable Specific Practice.

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.