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.