Applicability of Requirements Development (RD)

Is Requirements Development (RD) applicable for maintenance projects?

If the CMMI-DEV is applicable to your maintenance projects, then the short answer is YES!

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.

How Can I Manage Both Legacy and Maintenance Projects?

The nature of the work does not preclude the organization from having to follow processes. The organization simply has to define the processes correctly for the different types of work and domains. For a Maturity Level 2 (ML 2) organization, this approach comes down to how the organization defines a project. In my experience, clients who are managing legacy and/or maintenance projects initially define individual changes as a project and it kills them because of everything required by Project Planning (PP) and Project Monitoring and Control (PMC). So the organization then has to think about how they manage work. At what level do they create a project schedule? Is it for each change? Or is it for a group of changes? Or is it on an annual basis? Basically the changes for maintenance work tend to be treated as a “job jar” and the organization pulls different jobs out of the jar to work on. So my clients in this situation, then consider work being managed annually, meaning that there is an annual project plan covering staffing levels, training, etc. That is, most of the PP Specific Practices (SPs). Then when they work on a specific job or task, they have a mini-schedule that is reviewed and compared to the annual plan to ensure that everything is compatible and they work to the mini-schedule using the annual project plan.

For legacy projects, the project plan, if it exists, was created well before the organization heard of or considered implementing a process improvement model like the CMMI. Consequently whatever exists was not developed per the current PP processes and there is no business value to go back and attempt to retrofit the old plan to the current process. What does make sense is for all project re-planning and re-baselining activities from this point forward to follow the new PP processes.