SG 1 Establish Estimates
Estimates of project planning parameters are established and maintained.
Project planning parameters include all information needed by the project to perform the necessary planning, organizing, staffing, directing, coordinating, reporting, and budgeting.Estimates of planning parameters should have a sound basis to provide confidence that any plans based on these estimates are capable of
supporting project objectives.
Factors that are typically considered when estimating these parameters
include the following:
· Project requirements, including the product requirements, the requirements imposed by the organization, the requirements imposed by the customer, and other requirements that impact the project
· Scope of the project
· Identified tasks and work products
· Technical approach
· Selected project life-cycle model (e.g., waterfall, incremental,
spiral, etc.)
· Attributes of the work products and tasks (e.g., size or complexity)
· Schedule
· Models or historical data for converting the attributes of the work products and tasks into labor hours and cost
· Methodology (models, data, algorithms) used to determine needed material, skills, labor hours, and cost
Documenting the estimating rationale and supporting data is needed for stakeholders’ review and commitment to the plan and for maintenance of the plan as the project progresses.
SP 1.1 Estimate the Scope of the Project
Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. The WBS evolves with the project. Initially a top-level WBS can serve to structure the initial estimating. The development of a WBS divides the overall project into an interconnected set of manageable components. The WBS is typically a product-oriented structure that provides a scheme for identifying and organizing the logical units of work to be managed, which are called "work packages." The WBS provides a reference and organizational mechanism for assigning effort, schedule, and responsibility and is used as the underlying framework to plan, organize, and control the work done on the project.
Typical Work Products
1. Task descriptions
2. Work package descriptions
3. WBS
Subpractices
1. Develop a WBS based on the product architecture.
The WBS provides a scheme for organizing the project’s work around the products that the work supports. The WBS should permit the identification of the following items:
· Identified risks and their mitigation tasks
· Tasks for deliverables and supporting activities
· Tasks for skill and knowledge acquisition
· Tasks for development of needed support plans, such as configuration management, quality assurance, and verification plans
· Tasks for integration and management of non-developmental items
2. Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule.
The top-level WBS is intended to help in gauging the project work effort in terms of tasks and organizational roles and responsibilities. The amount of detail in the WBS at this more detailed level helps in developing realistic schedules, thereby minimizing the need for management reserve.
3. Identify work products (or components of work products) that will be externally acquired.
4. Identify work products that will be reused.
SP 1.2 Establish Estimates of Work Product and Task Attributes
Establish and maintain estimates of the attributes of the work products and tasks.
Size is the primary input to many models used to estimate effort, cost, and schedule. The models may also be based on inputs such as connectivity, complexity, and structure.
Examples of types of work products for which size estimates are made include the
following:
· Deliverable and nondeliverable work products
· Documents
· Operational and support software
Examples of size measures include the following:
· Number of functions
· Function points
· Source lines of code
· Number of classes and objects
· Number of requirements
· Number of interfaces
· Number of pages
· Number of inputs and outputs
· Number of technical risk items
· Volume of data
The estimates should be consistent with project requirements to
determine the project’s effort, cost, and schedule. A relative level of
difficulty or complexity should be assigned for each size attribute.
Typical Work Products
1. Technical approach
2. Size and complexity of tasks and work products
3. Estimating models
4. Attribute estimates
Subpractices
1. Determine the technical approach for the project.
The technical approach defines a top-level strategy for development of the products. It includes decisions on architectural features, such as distributed or client server; state-of-the-art or established technologies to be applied, such as robotics, composite materials, or artificial intelligence; and breadth of the functionality expected in the final products, such as safety, security, and ergonomics.
2. Use appropriate methods to determine the attributes of the work products and tasks that will be used to estimate the resource requirements. Methods for determining size and complexity should be based on validated models or historical data.The methods for determining attributes evolve as our understanding of the relationship of product characteristics to attributes increases.
Examples of current methods include the following:
· Number of logic gates for integrated circuit design
· Lines of code or function points for software
· Number/complexity of requirements for systems engineering
· Number of square feet for standard-specified residential homes
3. Estimate the attributes of the work products and tasks.
4. Estimate, as appropriate, the labor, machinery, materials, and methods that will be required by the project.
SP 1.3 Define Project Life Cycle
Define the project life-cycle phases upon which to scope the planning effort. The determination of a project’s life-cycle phases provides for planned periods of evaluation and decision making. These are normally defined
to support logical decision points at which significant commitments are made concerning resources and technical approach. Such points provide planned events at which project course corrections and
determinations of future scope and cost can be made.
For Software Engineering
The determination of project phases for software typically includes selection and refinement of a software development model to address interdependencies and appropriate sequencing of software project activities.
For Systems Engineering
Identify the major product phase (e.g., concept exploration, development, etc.) for the current state of the product, expected future phases, and the relationships and effects among phases. Adjust planning parameters to account for relationships and effects among phases.
The project life cycle consists of phases that need to be defined depending on the scope of requirements, the estimates for project resources, and the nature of the project. Larger projects may contain multiple phases, such as concept exploration, development, production, operations, and disposal. Within these phases, subphases may be needed. A development phase may include subphases such as requirements analysis, design, fabrication, integration, and verification. Depending on the strategy for development, there may be intermediate phases for the creation of prototypes, increments of capability, or spiral model cycles.
Understanding the project life cycle is crucial in determining the scope of the planning effort and the timing of the initial planning, as well as the timing and criteria (critical milestones) for re-planning.
Typical Work Products
1. Project life-cycle phases
SP 1.4 Determine Estimates of Effort and Cost
Estimate the project effort and cost for the work products and tasks based on estimation rationale. Estimates of effort and cost are generally based on the results of analysis using models or historical data applied to size, activities, and other planning parameters. Confidence in these estimates is based on the rationale for the selected model and the nature of the data. There may be occasions where the available historical data does not apply, such as where efforts are unprecedented or where the type of task does not fit available models. An effort is unprecedented (to some degree) if a similar product or component has never been built. An effort may also be unprecedented if the development group has never built such a product or component.
Unprecedented efforts are more risky, require more research to develop reasonable bases of estimate, and require more management reserve. The uniqueness of the project must be documented when using these
models to ensure a common understanding of any assumptions made in the initial planning stages.
Typical Work Products
1. Estimation rationale
2. Project effort estimates
3. Project cost estimates
Subpractices
1. Collect the models or historical data that will be used to transform the attributes of the work products and tasks into estimates of the labor hours and cost.
For Software Engineering
Within the software-engineering area, many parametric models have been developed to aid in estimating cost and schedule. The use of these models as the sole source of estimation is not recommended as these models are based on historical project data that may or may not be pertinent to your project. Multiple models and/or methods may be used to ensure a high level of confidence in the estimate.
Historical data include the cost, effort, and schedule data from previously executed projects, plus appropriate scaling data to account for differing sizes and complexity.
2. Include supporting infrastructure needs when estimating effort and cost. The support infrastructure includes items needed from a development and sustainment perspective for the product.
For Software Engineering
Consider critical computer resources in the host environment, in the test environment, in the target environment, or in any combination of these. Computer resource estimation typically includes the following:
· identifying the critical computer resources for the software project and
· basing estimates of critical computer resources on allocated requirements
For Software Engineering
Examples of critical computer resources include the following:
· Memory, disk, and network capacity
· Processor power
· Communications channel capacity
· Workstation power
· Peripheral capacity
For Software Engineering
Examples of software-engineering facilities include the following:
· Host computers, peripherals, and networks
· Software test computers and peripherals
· Target computer environment software
· Software-engineering environment (i.e., software tools)
3. Estimate effort and cost using models and/or historical data. Effort and cost inputs used for estimating typically include the following:
· Judgmental estimates provided by an expert or group of experts (e.g., Delphi Method)
· Risks, including the extent to which the effort is unprecedented
· Critical competencies and roles needed to perform the work
· Product and product-component requirements
· Technical approach
· WBS
· Size estimates of work products and anticipated changes
· Cost of externally acquired work products
· Selected project life-cycle model and processes
· Life-cycle cost estimates
· Capability of tools provided in engineering environment
· Skill levels of managers and staff needed to perform the work
· Knowledge, skill, and training needs
· Facilities needed (e.g., office and meeting space and workstations)
· Engineering facilities needed
· Capability of manufacturing process(es)
· Travel
· Level of security required for tasks, work products, hardware, software, personnel, and work environment
· Service-level agreements for call centers and warranty work
· Direct labor and overhead
