Project Planning SP 1.2 - Task Attribute: Effort or Size?

Is it possible to establish estimates of work product and task attributes by means of task time estimates? Can the task effort be similar to the size of a task?

By going directly to task time estimates you have effectively skipped performing Project Planning Specific Practice 1.2. The intent of SP 1.2 is for you to perform some sort of basis of estimate for the project’s tasks and activities. This is a bottom-up approach. If you are not used to this approach, it can be a struggle at first to take a step backwards from task time estimates and really understand the underlying assumptions that people are making in their heads about the factors that are driving the task time estimates. Some very basic task attributes include estimating the number of pages in a document that is being produced or updated, the number of technical drawings being produced or updated for a hardware item, the number of new or modified interfaces, the number of new or modified screens , etc. Then based on your historical data from previous projects, it is possible for you to empirically determine a set of productivity factors that will convert these sizing parameters into effort and arrive at the task time estimates. The bottom line is effort of a task is not the same as the size of a task.

Do you think this practice would be Fully, Largely, Partially or Not Implemented? Would this be this a problem in a SCAMPI A appraisal? What do you think about that?

Taking this example out of context with everything else your organization is doing makes this a difficult question to answer. The appraisal team is the only group that would be qualified to make that judgment based on documented evidence and the interviews. However, as a Lead Appraiser, I would have to say that you have a problem that needs to be addressed before you conduct a SCAMPI. The SCAMPI rules state that if a Process Area is in the scope of the appraisal, then all of its Specific and Generic practices are applicable. And if you are not performing a practice, which may or may not be the case, then there could be issues in Project Planning that impact Goal Satisfaction and result in a Maturity Level 1 rating.

To provide you the best answer, you should be talking to your Lead Appraiser and have him or her give you the proper guidance on this issue. As a risk mitigation, I would recommend that you put a process in place to estimate sizing parameters that are then used to calculate effort. Your estimators are already doing this, but it sounds like they are doing it in their heads. You just have to break the process down into smaller steps to allow the sizing estimates to be captured first. There is benefit to doing this.

Project Tracking Through Milestones

We have a Project management process defined for covering Project Planning (PP) and Project Monitoring and Control (PMC). It includes a Work Breakdown Structure (WBS) (task effort size must be about 20 hours), estimation process, assigned resources, etc. We are using MS-Project for tracking the schedule, and each month there is an Excel report with a project status summary.

People think it is very heavy to track the all of the fine-grained tasks in MS-Project. They would prefer tracking the project through milestones in Excel.

I’ve heard about using the burn down chart in Scrum, and I know some organizations use agility within CMMI model.

It is possible to do that? Could we be more “agile”?

The short answer is yes. The CMMI does NOT prescribe any project management tool or level of tracking. These decisions are left up to the organization to make. Sounds like what you need is a process that fits your organization. If people are complaining that the tracking process is too cumbersome to use, then you should definitely examine other methods. Take a top down approach from the business goals and objectives. What project tracking information does a project manager need in order to determine if the business goals and objectives are being met? Once you answer this question, that will help you decide the proper level of project tracking and monitoring. If you are still having difficulty figuring out the best method, work with a CMMI consultant to help you define a process that will be the best fit for your organization.

How Do I Determine Estimates of the Size Attributes?

CMMI-DEV Project Planning (PP) Specific Practice (SP) 1.2 states 'Establish and maintain estimates of the attributes of the work products and tasks.'

During appraisals it has been noted that most of the time we are relying on expert knowledge to determine effort and cost rather than estimating the sizing attributes. Just using expert knowledge makes it difficult to improve our effort estimation, hence having a dedicated set of attributes is essential in order for us to improve our estimations. We have evaluated some comprehensive methods (e.g. Function Points), but these are not considered as beneficial to our projects. We are now looking for an approach that allows us to improve our estimates with a simpler method which could then be refined based on our needs. Would you please give me advice how to tackle this challenge?

What PP SP 1.2 is looking for is the Basis of Estimate for the work product. If you are estimating a document for example, what aspects or attributes of the document can you estimate that when combined with a productivity factor will yield effort and cost? You determine these attributes by analyzing the historical data from your organization’s past projects. So based on the project’s requirements, you could estimate the number of pages that would be written for a document, the number of figures or drawings that need to be created or modified, etc. These items are then sizing parameters.

For source code, you need to analyze historical data from past projects to give an empirical estimate. As you say, function points are comprehensive. A simpler method may be to classify your software requirements in categories such as interface requirements, display requirements, processing requirements, reporting requirements, etc. and then using your historical data determine the correlations between these requirements categories and code size. Many organizations start with this simple kind of estimation/prediction model and continually refine it by incorporating data from each new project until a fairly accurate estimation model emerges. This estimation model is then very specific to the organization and type of software development it performs.

Hope these ideas help.

Selection of Suitable Lifecycle Processes

Selection of a suitable lifecycle for the project/product is more of a technical issue. Then why is it covered in Integrated Project Management (IPM) rather than Technical Solution (TS)?

Selecting a suitable lifecycle is a function of the project requirements and the application domain. The selection is something that should be performed when planning the project activities, not while performing the actual software engineering activities. Selecting a lifecycle model and defining the project’s lifecycle phases are necessary for planning and estimating the project. That is why lifecycles appear in Project Planning (SP 1.3) and Integrated Project Management (sub-practice 1 of SP 1.1) . The selection of the lifecycle is a project management activity.

From another perspective, the purpose of Technical Solution is to design, develop, and implement solutions to requirements. And selecting an appropriate lifecycle model is an activity that needs to be done before you can design, develop, and implement a solution to the requirements.

Identifying Risks

What is the difference between PP SP 2.2 Identify Project Risk and RSKM SP 2.1 Identify Risks?

What you are asking about is one of the basic differences between Maturity Level 2 (ML 2) and Maturity Level 3 (ML 3). Project Planning (PP) is a ML 2 Process Area (PA) and Risk Management (RSKM) is a ML 3 PA. At ML 2, the project only needs to be able to identify risks and that is what PP Specific Practice (SP) 2.2 addresses. At ML 3, RSKM builds upon the foundation of identifying and tracking risks put in place by PP and Project Monitoring and Control (PMC). RSKM SP 2.1 therefore builds upon PP SP 2.2 by adding more rigor for risk identification. Just read the informative material and sub-practices for both SPs and you will immediately see and understand the difference.

Estimating Cost vs. Establishing the Project's Budget

What is the difference between Estimation of Project Cost (PP SP 1.4) and Establishing Project Budget (PP SP 2.1)?

Project Planning (PP) Specific Practice (SP) 1.4 addresses estimating the effort and cost for the project’s work products and tasks based on specified estimation rationale, models, and/or historical data. SP 2.1 takes this information for the individual work products and tasks, along with the major milestones identified in the project’s defined life cycle, any scheduling assumptions and constraints, and task predecessor/successor relationships to construct the project’s schedule and overall budget. Simply put, SP 1.4 concerns individual items in the project and SP 2.1 concerns the project as a whole.

Software Sizing

We are trying to achieve CMMI Maturity Level (ML) 3 in my company and we have decided to skip ML 2. So, now, one of our problems is related to software size estimation. We defined a proprietary method, based on Use Case Points and Function Points, but the practitioners are struggling with it. From your experience, what other methods have you seen or implemented in the companies with this same problem? Or, if a proprietary method was defined, what were the main aspects to take in account?

I would strongly urge you to forget the ML 3 Process Areas until you have mastered ML 2. There is a fundamental difference between how a ML 2 Project Manager approaches Project Planning (PP) and Project Monitoring and Control (PMC) vs. a ML 3 Project Manager. Estimation being one of the differences. Use Case Points and Functions Points are fairly sophisticated concepts and there are challenges with getting consistency in determining what each of these things are. I would recommend that you take a step back from the model and the projects and look at your historical project data. Use the actual effort, costs, etc. from previous projects to estimate a new project. Forget about Use Case Points and Function Points for now. Once you have mastered being able to use historical information to build an empirical estimation model, then it might make sense to add a layer of sophistication by considering Use Case Points or Function Points.

Another recommendation is let the Project Manager create the project estimates and then review them with the practitioners as a sanity check rather than ask the practitioners to create the estimates. Over time as the organization gains experience estimating projects etc., then it makes sense to involve the practitioners up front in the estimation process. You have to learn to crawl first with estimation before you can sprint with the big boys.

Product Planning and Configuration

It is common knowledge that Maturity Level 2 is project specific, and still I find at times Lead Appraisers asking funny questions during SCAMPI A appraisals. Quite recently, one of my friends told me that his Lead Appraiser is looking for planning at the product level, as well as Configuratuion Management at the product level. I was a bit amazed, thinking that Maturity Level 2 focuses on Project Planning, not product planning. What do you think about this situation? Have you been faced with this situation before? Is there a workaround for it?

From what you describe, it sounds like this Lead Appraiser could be misinterpreting the CMMI and possibly misleading the organization. The CMMI is quite clear that the Project Planning (PP) Process Area (PA) is for project planning purposes, not product planning.

"The purpose of PP is to establish and maintain plans that define project activities."

However, sometimes the difference between project and product can be blurred. By not knowing the context of the situation you described, the Lead Appraiser may have been trying a different approach to draw project planning information out in the interview sessions.

In one respect, it really doesn’t matter the line of questioning in a SCAMPI interview session. The Lead Appraiser could really ask about any topic. However, once he or she starts deviating from the CMMI, they are on shaky ground and could lose credibility. What does matter however, is the set of findings produced by the Lead Appraiser and the Appraisal Team. If there are findings associated with product planning that cannot be tied to the satisfaction of a CMMI Specific Goal or a Specific Practice, then these would be non-model findings and should have no impact on the resulting appraisal rating. However, if these non-model findings do impact the appraisal rating and the Lead Appraiser and Appraisal Team fail to demonstrate the linkage to Goal and Practice satisfaction/implementation, then the Lead Appraiser has not correctly performed his or her Lead Appraiser duties and the SEI should be informed about this issue so it can be investigated.

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.

Estimation Rationale

I guess this seems little silly, but I needed more clarity on it. According to PP 1.2, attributes need to be estimated. Can anyone give me examples of attributes for project? I guess, when we say small, medium , large type projects they form the characteristics of project and not the attibutes. For sure, once we are clear with attributes we can surely ensure that our effort estimates (PP 1.4) are based on estimation rationale. How will project attibutes map up to estimation rationale?

What PP SP 1.2 is addressing is the Basis of Estimate for the project tasks, deliverables, etc. Basically this practice is looking for the sizing attributes that you use to ultimately determine your effort estimates. For a document, an attribute you might estimate is the number of pages for the document that have to be added, modified, or deleted. For hardware, it might be the number of drawings you have to maintain. For software, it might be the number of lines of code, function points, etc. Just using small, medium, or large doesn’t provide a Basis for Estimate. The Basis of Estimate is then your estimation model that is derived from the historical data from prior projects going through this same process. When you first begin to use the Basis of Estimate approach you may not have very good data, or no data at all. So the best you can do is make a guess as to the estimate (SWAG or engineering judgment). But over time as you collect the project data from each project, you will be able to refine this approach and have much better estimates. Then you take these sizing parameters or attributes and apply a productivity factor, again based on your historical data, to arrive at the effort and cost estimates in SP 1.4.

Definition of SOW

I would like to know what is the content of the Statement of Work and how does this document meet requirements of the CMMI?

As a best practice with definition questions, the first place to look is the CMMI Glossary. In this case there is a definition of Statement of Work (SOW) in the Glossary. “A description of contracted work required to complete a project.” In other words, the SOW contains the requirements for what you have to delivery to the customer. And there are varying levels of detail from SOW to SOW depending on the size, criticality, and nature of the work. For large government contracts, the SOW may also contain the Work Breakdown Structure (WBS) for the program/project as well. At a minimum, the SOW will contain the customer’s requirements that the organization will further develop. So the SOW supports RD and may also support PP.

CMMI Implementation

I recently joined a company where there is no process and management recruited me to implement the CMMI. The organization has different business units. Though everyone sits together, they work very differently. I conducted a Gap analysis based on the CMMI Level 2 processes and here are the findings:

1. Project Planning & PMC -- they create project plans and they have the regular project team meetings and they share the minutes. Each team has their own format and templates. The projects don't really do estimations. Can we satisfy the PP & PMC PA'ss without doing any estimation? I know it can't be that way, but can it be tailored?
2. Requirements Management: Some of the business units have CCBs to discuss change requests and other business units discuss requirements changes in their project team meetings. The most significant gap I found is in Requirements Traceability. Traceability of Customer requirements to the Functional Requirements and Traceability of Use cases to the Test cases are missing. Is this reason enough to fail the RM PA? One of the Engineering directors asked me how much traceability you need to satisfy this condition. At that time I said 100% of all the requirements. Then I also read from somewhere that it is OK to define that we maintain traceability for at least the MUST BE CUSTOMER REQUIREMENTS. Traceability of other requirements can be made optional. Can it be possible like that?
3. Configuration Management: The projects thought they have a CMP which is embedded in the project plan. What I found missing are the Configuration Audits ( PCA & FCA). Is it possible to satisfy the Configuration Management PA without doing Configuration Audits to check the document status, builds, and backup strategy?
4. PPQA: One of the business units has a Software Quality Assurance plan, but it is done by one of the testers from another project. As a part of PPQA the SQA will do some spot checks based on a pre-defined checklist, which includes Project Planning, Risk Management, Project Monitoring and Control, Integration and releases. But I guess this can be improved by my role as a independent software quality engineer.
5. M&A: I am very much worried with this process area, as of now the organization status is nil with respect to metrics collection, they don't have a metrics database and no metrics have been defined yet. Is it OK to start now to form a team to do some reasearch and come up with metrics definitions, deploy them and start collecting data? My question is how much data do we need to collect to satisfy this PA? And do we need to provide evidence of analyzing these collected data and show some improvements steps taken at the time of SCAMPI apprisals? How long will it take in general to satisfy the Measurement & Analysis PA?
6. SAM: can we tailor this PA if we are not dealing with suppliers? If yes how can it be possible?
   

The directive from the Leadership team is to acheive CMMI Level 3 by end of 2009. I was baffled to hear this. Under these circumstances, what are the chances of getting CMMI Level 3 or my traget is at least CMMI Level 2? That is what my initial target. Can I acheive CMMI Level 2 by the end of 2009? If so, what are the things I need to address?

Here are some of the things I have already started:

1. CMMI Overview training to all the teams
2. Dailogue session on metrics identification
3. Looking into some Requirements tools which provide Traceability
4. Need to push the project team to have configuration audits.

In addition we already have established a process data base and the processes are defined and templates are being used from the parent organization. Since our company is a multi-site company, one of our counter parts has already acheived CMMI Level 3. We will be using the same process database and their templates. I thinking of providing their training on each Process Area as well. Is this a correct way to use the processes and templates of our parent organization? If not, do we need to establish our own local process data base?

First of all, I sympathize with you and the challenges you face. I applaud the fact that you had the foresight to conduct a Gap Analysis of the organization. You have highlighted a number of key weaknesses within the organization. However, to provide you meaningful feedback on all of your points would require working directly with you and your company.

1. What is your CMMI experience? Have you taken the SEI’s Introduction to CMMI class? If not, I strongly recommend that you and possibly those others in your company who are responsible for your processes take the three day class. The class should provide you a more thorough understanding of the CMMI, its interpretations, and material for constructing an internal Overview class.
2. You have identified some serious deficiencies within the organization in all of the ML 2 Process Areas. These need to be analyzed, addressed, corrected, solutions implemented, and then re-evaluated some months into the future before you can consider a formal SCAMPI at any Maturity Level. The length of time before the next evaluation is a function of a number of factors: number of people in the organization, number of projects, typical project duration, how much time and other resources are dedicated to process improvement, etc.
3. The organization needs to first implement Maturity Level 2 to form a firm foundation before considering moving to Maturity Level 3. The issues you have identified are fairly typical. Basically, it sounds like your organization does not perform PPQA or MA and is challenged with Project Management, Requirements Management, and Configuration Management. The first steps here should be to identify the necessary skills-based training classes you need to bring in-house and train your staff on these concepts. If you just purchase tools and push for audits, you most likely will not achieve the desired effect. You have to understand your process first and the reasons for why it is important to perform each of the steps.
4. Since another division has already achieved ML 3, it is a good idea to learn from their mistakes. But be very careful of the temptation to “clone” their processes and procedures. You have to implement the processes and procedures that match the way you conduct business today.
5. Based on what you have outlined, and given how much time and effort it could take just to address the ML 2 issues, I would say that ML 3 is out of the question for 2009. You could conduct a ML 3 SCAMPI A by the end of this year, but in all likelihood it would not be successful.
6. The best suggestion I have for you is to hire a CMMI consultant and Lead Appraiser to provide you with the proper advice and guidance. Otherwise, you could be spending a lot more time and effort than originally anticipated.

A Question About Estimation

I'm a bit confused about what the CMMI requires for estimation. Is it valid for us to define our process as simple as guessing? Could we use something similar to Planning Poker or other similar agile techniques? The problem is that we've been told we need to have a quantitative and repeatable process for estimating in order to meet Project Planning (PP) SP 1.4 "Estimate the project effort and cost for the work products and tasks based on estimation rational." But in reality we don't have historical data and many of us think estimating is subjective anyway.

When you start implementing Maturity Level 2 there is no expectation that you have any historical data for estimating. The best you can do at that point is guess, SWAG, or use engineering judgment. One of the characteristics of being a Maturity Level 2 organization is that you are learning. You are learning what it means to estimate a project. You are learning how to improve your estimates so that over time you will be able to produce accurate estimates to build the foundation to allow the organization to move to Maturity Level 3. So, by the time you are ready for a Maturity Level 2 SCAMPI A appraisal, the expectation is that you have a repeatable estimation process (repeatability is at the core of Maturity Level 2) that is based on historical project data. Estimation is not difficult, it just takes a little bit of brain power and being systematic in your approach. One of the purposes of achieving Maturity Level 2 is moving from being subjective in estimation to being objective. If you have people that believe estimation is subjective, then I am afraid that you are still operating as a Maturity Level 1 organization.

Lifecycle vs. Process

What is the relationship between a project's lifecycle (PP SP 1.3) and the project's process, which is part of the project plan (PP SP 2.7 and GP 2.2 for all PAs). I realize that the lifecycle is used to determine decision points or project milestones. However, doesn't the project's process used also determine that? If a project selected a waterfall lifecycle, wouldn't a very high-level description of the project's process also be do requirements, design, code and test.

The project's software development lifecycle (SDLC) specifies managable project phases, such as analysis, design, code, and test. The SDLC is one of the necessary components, along with the tasks, activities, and work products, that are used to estimate the scope, effort, and cost for the project. Each project phase usually concludes with a decision point and/or project milestone. The project's processes govern the tasks and activities that occur within and across each lifecycle phase. The project processes do not determine when project milestones occur and neither do they determine which project milestones occur. These two aspects of the project are determined by the SDLC.

The other aspect of the project's SDLC is that the project's processes are a function of the SDLC chosen for the project. If the project uses a waterfall SDLC, the project's processes would be very different from those needed to support an agile SDLC.

What is mandatory to have about a WBS? What must a top-level WBS contain?

The CMMI defines Work Breakdown Structure (WBS) as an arrangement of work elements and their relationship to each other and to the end product. What this definition means is that the WBS is a basically a list of all of the tasks that must be performed from the start of the project to the conclusion of the project. So typically the WBS includes the tasks associated with:

1. Managing the project
2. Managing the configuration(s) and configuration items
3. Managing the requirements
4. Managing the software engineering activities of requirements engineering, design, development, test, build, and delivery
5. Managing the suppliers, if there are any
6. And perhaps others that I may have overlooked

This list of tasks/activities applies to any type of development from the legacy waterfall to Agile. Just the specific details will differ. Now WBS only appears in four locations in the CMMI-DEV: PP, PMC, IPM, and RSKM.

PP SP 1.1 addresses the top-level WBS that you use to estimate the scope of the project. The intent of this practice is not to develop a detailed WBS at this point, but to start with a somewhat “generic”, for the lack of a better term, WBS that applies to all similar projects in the organization that the Project Manager can use to structure his or her initial estimation efforts. Then over the life of the project, as the PM and team gain knowledge about the project, the WBS becomes more detailed. In some organizations, there is confusion about the term WBS because if the organization is under contract to a customer, the contract may include a WBS. Depending on the size and scope of the project, the contract WBS may not be the same as the WBS for the project.

PMC Introductory Notes refers to the WBS in the context of tracking project progress per the project schedule or WBS.

IPM SP 1.4 sub-practice 7 refers to the WBS in the context of having very tight control of the initiation and completion of the tasks described in the WBS.

RSKM SP 2.1 Hint refers to the WBS as a source for identifying risks.

So the bottom line, is that the most guidance the CMMI gives for the WBS is in PP. There are no specific requirements for what a top-level WBS must contain. What you should do is structure the WBS based on the product architecture, application domain, and methodology. To keep the WBS at the right level, identify groups of related activities that are usually performed together. Each activity group should be defined in sufficient detail so it can be reasonably estimated, have responsibilities assigned, and placed on the project schedule. And finally each activity group should have its outputs/work products clearly defined. If you cannot define one or more work products for an activity group, then you probably have not grouped the activities correctly. And as you grow in knowledge and maturity in using the WBS, you may evolve your WBS so that the tasks and activities it contains are networked (predecessor/successor relationships) to enable critical path analysis.

Query on ML 3 and ML 4

What is the significance of Maturity Level 3 and Maturity Level 4? And can you explain to me what is Integrated Project Management?

What broad questions! These questions really need a long in depth answer and are addressed very well in the Introduction to CMMI class. So first off I would suggest that you find an opportunity to take this class. Please visit http://www.ppqc.net/training/training.htm for more information about the class.

To briefly answer these two questions, the answer needs to address ML 2 as well. So I will start with some definitions from the CMMI book.
Process Area (PA) – a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area.
Maturity Level (ML) – degree of process improvement across a predefined set of process areas in which all goals in the set are attained. An ML is a defined evolutionary plateau for organization process improvement. Each ML matures an important subset of the organization’s processes, preparing it to move to the next ML.
Maturity Level 1: Initial – processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment to support the process. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes.
Maturity Level 2: Managed – projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions, The process discipline reflected by ML 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
Maturity Level 3: Defined – processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for ML 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined process by tailoring the organization’s set of standard processes according to tailoring guidelines.
Maturity Level 4: Quantitatively Managed – the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of the processes.
Maturity Level 5: Optimizing – an organization continually improves its processes based on a quantitative understanding of the common causes of variation inherent in processes.

Given these definitions and explanations, one of the fundamental differences between ML 3 and ML 4 is that at ML 3 the organization is learning how to use a standard set of processes, tailoring them to the individual project needs, and collecting enough process data such that Process Performance Baselines and Process Performance Models can be built and used at ML 4 to quantitatively manage projects and statistically manage sub-processes to achieve the organization’s quality and process performance objectives.

To answer the second question, you first need to understand the Project Planning (PP), Project Monitoring and Control (PMC), and Integrated Project Management (IPM) PAs. PP and PMC are ML 2 PAs that address the basic project management practices of planning a project, creating a project plan, and using that project plan to track and monitor the project. At ML 2, the organization typically is learning how to create accurate and realistic estimates by building estimation models. It takes time to refine these estimation models, so an ML 2 organization is expected to frequently revise and re-baseline the project plan as the projects get smarter about estimation. At ML 3, one of the project management expectations is that the project estimates are now accurate and realistic. So, rather than constantly update the estimates to match the actuals as done at ML 2, the Project Manager now manages the project to the estimates, meaning that the PM can now fairly accurately predict early on in the lifecycle whether or not the project will hit its downstream targets and take appropriate corrective action to mitigate these risks. The other differences between IPM and PP/PMC include establishing the project’s defined process by applying appropriate tailoring criteria to the organization’s standard processes, establishing the project’s work environment, integrating the various plans that comprise the project plan, managing the project using the integrated plans, and managing the project’s relevant stakeholders. In other words, IPM builds on the project management foundation established by PP and PMC.

This a lengthy explanation but only a surface treatment on these subjects. Again I strongly recommend to anyone interested in this topic that you attend an offering of the Introduction to CMMI v1.2 class. You will go into these concepts in much greater detail and you will come out with a much better understanding of the model, PAs, and MLs than I can convey in this blog.

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.