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.

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.

Understanding How Project Planning Evolves from ML 3 to ML 5

The primary difference between project planning at Maturity Level 3 (ML 3) and Maturity Level 5 (ML 5) is how you construct the project’s defined processes. At ML 3 a new project starts from the organization’s set of standard processes and applies the appropriate tailoring criteria or guidelines for the project, based on the project requirements. At Maturity Level 4 (ML 4) and ML 5 a new project first has to define what its quality and process performance objectives are based on the organization’s quality and process performance objectives (QPPOs). Then the project looks at the organization’s set of standard processes and selects the processes or sub-processes that are capable of being quantitatively and statistically managed to achieve the project’s QPPOs using the established Process Performance Baselines and Process Performance Models. These processes and sub-processes are selected based on historical stability and capability data along with the appropriate tailoring guidelines and criteria to construct the project’s defined process.

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.