Project Estimating Procedures

Information Resource Management Commission (IRMC) Procedure for Estimating Costs and Delivery Dates
Effective Date: 04/06/1999 Revision Date: 02/04/2003 ___________________________________________________________________________________________
I.
Purpose
The "Information Resource Management Commission (IRMC) Procedure for Estimating Costs and Delivery Dates" is written to provide agencies with a consistent, predictable, repeatable, and measurable process to ensure that project estimates are complete, accurate, and defensible. Also, this document is designed to provide the project manager (developer) and the project sponsor (client) with detailed instructions on how to comply with the "Information Resource Management Commission (IRMC) Standard for Estimating Costs and Delivery Dates." The purpose of the IRMC Procedure for Estimating Costs and Delivery Dates is to ensure the prompt and efficient capture, tracking, analysis, and response to client requests for agency information technology (IT) estimating services. The Project Proposal Estimate form (sample attached as Appendix C) is a structured vehicle and method of requesting and providing estimating service to project sponsors. This procedure will detail a proposed project estimating process "work bench" that can be used to organize, control, prioritize, and coordinate client requests for project estimating service as part of pre-development process activities, during the development process, and as part of the postdevelopment process. The goal is to provide an estimating workbench that is workable, logical, consistent, self-improving, and in compliance to IEEE Standards.
II.
Scope
The IRMC Procedure for Estimating Costs and Delivery Dates may be used by agency information technology (IT) personnel providing project estimating services to clients for application development projects, feasibility studies, planning projects, and research projects.
III.
Objective
The objective of the IRMC Procedure for Estimating Costs and Delivery Dates is to provide a disciplined process approach to project estimating by defining a standard methodology, structure, format, and procedure for the development and presentation of project sizings, approximations, and estimates. This procedure will provide a set of standard process definitions, a list of common project assumptions to be evaluated in most estimating activities, and provide a portfolio of estimating techniques which may be used by agency personnel to satisfy estimating requests for IT products and services.
P:\IRM\Private\QA\ESTIMATE\PROCEDURES.DOC
Page 1 of 21
02/13/03 9:12 AM
Effective Date: 04/06/1999 Revision Date: 02/04/2003
_____________________________________________________________________________ IV. Procedure Definitions
A project is defined as a unit, or several related units, of work that have a defined beginning and ending date with identified deliverables of either products or services. The four (4) project categories are: 1. Feasibility Study - A project designed to prove, or disprove, the appropriateness of the technology solution under existing constraints. Sometimes called a "proof-of-concept" project, a feasibility study is a method used to estimate technical, cost, and resource data to determine the potential of achieving project objectives. 2. Research Project - A project type essentially exploring options for developing new systems or work products. 3. Development - The sum of all tasks and activities necessary to build a software product. Development efforts involve the creation of an automated system, regardless of size. 4. Planning - A project intended to gather, or predict, the sequence of activities and resources needed to complete a work effort. In addition to the types of projects detailed above, agencies may be required to provide clients with various types of project estimates. Estimating will occur at different points within the project system development life cycle. Agencies may be asked to provide a high-level planning estimate or may be required to provide a very precise, iteratively developed, estimates for work to be performed at the project phase level. The following definition of estimate types are key to the completion of the Project Proposal Estimate form. A sizing is generally a high-level approximation that is used to make strategic business decisions such as: initiate the project or determine another direction, purchase the system versus build the system. Sizing estimates are usually stated in terms of overall effort (hours of work), cost (dollars), or general implementation time frames (e.g., 4Q1999). The degree of preciseness and the confidence level of sizing estimates will vary greatly based on previous experience and specific knowledge of project objectives. Sizing implies a rough order of magnitude estimate or ball park estimate and may have a degree of preciseness of plus or minus 75%. Sizing is the least precise of all estimates and should only be used in pre-development process planning activities or in the strategic planning process.
Page 2 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Approximations are project assessments of costs and delivery dates. Approximations are developed for total project activities, multiple phases of a project, or multiple components of a project plan. Approximations should have a higher degree of preciseness (plus or minus 50%) and should be used in pre-development process estimating as well as tactical planning functions. Planning approximations forecast total systems implementation costs and are developed early in the project system development life cycle (SDLC). Approximations with this range of specificity are best suited for project funding or budgetary purposes. Agencies should use approximations to determine general project completion time frames. Approximations are not as precise as estimates but are more precise than a sizing.
Estimates are detailed project phase projections of resource assignment, delivery dates, and budgeted costs. Estimates should be specific assessments of costs and delivery dates for a clearly defined work unit or project phase. Estimates should be used to plan, schedule, and monitor project activities and are usually stated in terms of work effort, cost, and lapsed time to complete. Estimates are provided with the highest level of precision (plus or minus 10%) and should be formally defined and baselined for all development process activities. Baseline estimates should be used as project commitments and plan versus actual performance measurements. Agencies should use estimates to determine specific development phase, or activity, completion time frame and cost.
V.
Field Definitions
The Project Proposal Estimate form is composed of nine (9) major sub-sections. These subsections are: Estimate Header Information (top of page 1), Estimated Direct Effort Hours (page 1), Estimated Indirect Effort Hours (page 2), Total Estimated Effort Hours (page 2), Project Duration Estimate (page 2), Estimated Project Cost (page 3), Estimate Degree of Precision (page 3), Estimate Approvals (page 3), and Project Proposal Estimating Assumptions (page 4).
Page 3 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ A. Estimate Header Information (page 1)
"Project Name:" the name of the project to be estimated. Sponsor's Name: the name of the client / partner requesting the estimating service or sponsoring the project. Estimator's Name: the name of the person providing the project estimate. Baseline Estimate Date: the date (in the format MM/DD/YYYY) of the original baseline project estimate. Revision Number: indicates the number of estimate revisions ("0" for original and incremented by 1 for each revision. "Revision Date: the date (in the format MM/DD/YYYY) of the latest estimate revision.
Prior to completing the hour and cost estimate on pages 1 and 2 and the project assumption matrix on page 4, the person providing the estimating service should ensure that the following four (4) questions are answered. The four key questions are: 1.) 2.) 3.) 4.) What will the estimate be used for? What degree of preciseness is required for the estimate (plus and minus what percentage)? What are the project assumptions used to develop the estimate? and What estimating approach (tool, technique, or methodology) will be used to develop the estimate?
Once these four questions have been answered, the estimator may proceed with completing the estimating form.
B.
Estimated Direct Effort Hours (page 1)
The Estimated Direct Effort Hours portion of the Project Proposal Estimate form is a cost estimate in hours of the work to be performed. The categories correspond to the IEEE Standards for the system development life cycle (SDLC) phases. The purpose of this section is to accumulate an estimate of labor hours that will be needed to complete the project.
Page 4 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ C. Estimated Indirect Effort Hours (page 2)
Based on the direct labor hours, estimates should be provided for indirect effort hours - factors that are common to all projects (e.g., change management, problem management, project meetings, communications, rework, and project management functions). Use the Total Estimated Direct Effort Hours (sub-total A on page 1); and indicate the percentage of time needed to perform indirect effort activities. Multiple the percentage of indirect hours times the Total Estimated Direct Effort Hours and indicate the result in effort hours for each category (B.*). The total of all estimated indirect hours should be summed and noted on page 2 line B - Total Estimated Indirect Effort Hours.
D.
Total Estimated Effort Hours (page 2)
After both direct and indirect effort hours have been determined, the Total Estimated Effort Hours may be calculated by summing Total Estimated Direct Effort Hours (sub-total A on page 1) with Total Estimated Indirect Effort Hours (sub-total B on page 2).
E.
Project Duration in Weeks (page 2)
Critical personnel factors such as developer availability in hours per week, number of development team members, and performance percentage should be detailed on the form. The product of these three values divided into the Total Estimated Effort Hours (C) yields an estimate of Project Duration in Weeks (or lapsed time to complete). The number of weeks that the project will take to complete should be indicated in item G on the bottom of page 2.
F.
Estimated Project Cost (page 3)
The remaining fields of the Estimated Project Cost section provide the client with a dollar summary of estimated project costs. Certain fields may be calculated (e.g., Estimated Labor Cost equals Total Estimated Effort Hours" (sub-total C) multiplied by the agency Cost Allocation Rate), and other fields must simply be estimated (e.g., Projected Hardware Cost). Once all of the factors in this sub-section have dollar estimates, the Estimated Project Cost (sub-total P) may be completed by summing all defined dollar cost factors.
Page 5 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
G.
Percentage Degree of Precision (page 3)
After the project estimate (hours, elapsed time, and dollars) has been developed, the estimator must define the estimate's degree of precision as a percentage level of confidence (over and under) with the estimate. This percentage is determined by the type of estimate provided, estimating methodology, degree of precision needed by the client, and the project assumptions defined in the Project Proposal Estimating Assumptions (page 4) of the Project Proposal Estimate form.
H.
Approvals (page 3)
This section of the Project Proposal Estimate form is reserved for estimate approvals. The estimator must sign the estimate form and the estimate must be accepted by both agency IT management and the project sponsor, or designee.
I.
Project Proposal Estimating Assumptions (page 4)
The Project Proposal Estimating Assumptions section is a detailed summary of project assumptions used in the estimating methodology. Project assumptions may be identified by the requester, assumed by the estimator, defined in the project objectives, or specified by the highlevel business requirements.
Type of Estimate: Type of project estimate to include: (For more detail about the types of estimates, refer to section IV, page 2, of this document.) S = Sizing. A = Approximation. E = Estimate.
Page 6 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
Estimating Method: Methodology used to complete the estimate. Estimating methodologies may vary and might include:
INT = Intuitive estimating based on application knowledge and experience of the estimator. HIS = Historical estimate based on prior successful project of a similar nature and scope. ISM = Industry standard model (Estimate one phase and model estimates the remaining phases). LOC = Lines of code (COCOMO tool). FPA = Function point analysis (IFPUG). WAC = Weighted average calculation (Weighted Average Cost) of one optimistic estimate, plus one pessimistic estimate, plus four times an average estimate divided by six (1O + 1P + (4 x N) / 6). TOP = Top-down estimating involving the evaluation of project factors determining project complexity with estimates by phases. BOT = Bottom-up estimating refers to task by task work break down structure estimates added up to provide a detailed overall estimate. ITS = Iterative estimate based on task by task bottoms up estimates refined after completion of each phase or check point by taking actuals for completed phases and estimating all other phases, or CON = Consensus of experts (Wide Band Delphi Technique) derived from brain storming project estimates. CAS = Tool-based software estimate from CASE tools such as KnowledgePLAN, ABT Bridge Modeler, Platinum Protellecis Enterprise PM. OTH = Other, please specify in "Project Assumptions" on page 4.
Project Type: Proposed project type to include: (For more information about project types, refer to section IV, page 2, of this document) FEA = Feasibility Study. RES = Research Project. PLN = Planning Project. DEV = Development / Transfer / Purchase. OTH = Other, please specify in "Project Assumptions" on page 4.
Page 7 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Project Driver: Project sponsor priority defined as: T = Time B = Budget or F = Function
Project Platform: MF = Mainframe PC = Personal Computer LN = Local Area Network WN = Wide Area Network CS = Client Server or OT - Other, please specify in "Project Assumptions" on page 4
Quality Concern: H = High A = Medium L = Low
Development Approach: Although the development approach may vary, and hybrid development approaches may be used, the most common system development life cycle (SDLC) approaches are: TRA = Traditional waterfall phased approach PRO = Prototype development RAD = Rapid application development SPL = Spiral development ITD = Iterative development or OTH = Other, please specify in "Project Assumptions" on page 4.
Schedule Concern: H = High A = Medium L = Low
Page 8 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Project Size: System development life cycle project category is based on the size and complexity of the project and includes: CAT 1 projects usually involve no analysis or programming and typically have the following characteristics: - The work will be carried out by a single staff member within a time period of four weeks or less, - Usually there is no formal project work plan or budget, - There is a single user contact, - Specific requirements are usually well understood at the time of the estimating request, - Examples of Category 1 projects would include hardware / software configuration requests, packaged software installation that involve no code modification, JCL changes, training requests, small consultation estimates, and documentation requests. CAT 2 projects are estimating requests involving minor analysis and programming and usually have the following characteristics: - The project will be implemented by multiple staff members within a period of four weeks or less, - The proposed project is less than 300 hours of effort, - Very often, there will be no formal work plan or budget, - There are one or two sponsor contacts in a single agency / division, - Specific requirements are well understood at the time of the estimate, - Examples of Category 2 projects estimates include ad-hoc project requests, planned maintenance to existing systems involving limited programming and testing, and diagnostic (debugging) requests. CAT 3 projects are estimating requests that involve significant analysis, programming, or testing and typically have the following characteristics: - The project will utilize up to five staff and / or contractors within a period of six months or less, - There will be a formal project approval / budget authorization and project work plan, - Project status reporting to agency management will be required, - The project may involve outside purchases that may be accomplished through the use of the State convenience contract, - There are several sponsor contacts in more than one agency or division, - Specific requirements are not clearly understood at estimation time, and
Page 9 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ - Examples of Category 3 projects include packaged system installations requiring extensive programming, interface code, and testing; modifications to existing systems; or the development of small to moderately sized new systems. CAT 4 projects are characterized by substantial visibility to agency management. These projects will involve significant analysis, design, programming, and testing, and usually involve a high level of risk in implementation. Category 4 projects estimates have the following characteristics: - The project work will utilize five or more project staff and / or contractors within a period of more than six months, - Due to the complex nature of the project a formal project approval / budget authorization and project work plan is required, - Project status reporting at the IRMC "KEY PROJECT level will be required, - Projects in this category may also be funded by federal or state automation grants and as a result may be subject to specific reporting requirements, - The project may involve significant outside purchases of hardware, software, or consulting services that will require the Request for Proposal (RFP) process, - There are several sponsor contacts in more than one agency or division, - Specific requirements are rarely understood at this time in the project planning cycle, and - Examples of Category 4 projects include packaged system installations requiring extensive programming, interface code, and testing; extensive modifications to existing systems, or the development of large new systems; and projects involving new technologies.
Cost Concern: H = High A = Medium L = Low
"SDLC Tool: Definition of the proposed system development life cycle and project planning and scheduling tool to be used in project management activities: MTH = Method/1 (Methodology) ABT = ABT Project Manager's Workbench (planning tool) MSP = Microsoft Project (planning tool) OTH = Other, please specify on page 4 "Project Assumptions".
Page 10 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Function Complexity: S = Simple with no interface systems A = Average with minimum (up to 2) system interfaces or C = Complex with multiple (more than 2) system interfaces and dependencies.
User Involvement: H = Highly involved A = Average involvement or L = No significant user involvement in the project
"Function Stability:" H = High degree of function definition and understanding with minimal changes required prior to implementation. A = Average, basic functionality is known but will have managed change control during project implementation or L = Low, functional requirements are not known and will change significantly
"Development Team Skills:" S = Basic application development skills required A = Traditional development skills matrix required (project leader, analyst, code, etc.) C = Complex and unique application development skills required.
Availability of Resources:" H = High availability of in-house resources capable of completing the project A = Medium availability of resources capable of completing the project or L = Low availability of in-house resources needed to complete the project.
Page 11 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Clarity of Project Requirements:" H = High clarity in requirements definition, easily understood by agency IT and clearly defined by the client A = Average clarity, all function not clearly defined or L = Low clarity with a fuzzy definition of requirements where the impact is not clearly understood by agency IT.
Management Focus: Y = Yes for high visibility management focus projects or N = No management focus at this time.
Extended Team Complexity: S = Basic client / IT team organization A = Average IT and agency responsibility matrix or C = Complex multi-functional relationship with multiple agencies involved in development, implementation, and support.
"Responsibility Definition: S = Simple, clearly defined, and accepted project responsibilities A = Average responsibility matrix with some responsibilities understood but not clearly defined nor accepted or C = Complex matrix of responsibilities where responsibilities are not clearly defined nor understood and accepted.
Technology Availability: H = General high availability of all proposed technology tools and techniques A = Availability of some technology tools and techniques or L = Low availability of required technology tools and techniques. Technology Experience:
Page 12 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ H = High level of experience using project tools and technologies A = Some level of experience using project tools and techniques or L = Low level of experience utilizing proposed project technologies.
Degree of User Acceptance Testing: H = High level of user acceptance testing required A = Average level of user acceptance testing required or L = Low level of user acceptance testing required.
Complexity: H = High overall project technical complexity A = Average overall project technical complexity or L = Low overall project technical complexity
Training Requirements: H = High level of user training required A = Average level of user training required or L = Low level of user training required.
Documentation: H = High level of project documentation required A = Average level of documentation required or L = Low level of project documentation required.
Funding Availability: Y = Yes, funding is available and committed by the sponsor, or N = No management commitment for funding of the project at this time.
Page 13 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
"Project Risk: Overall project risk must be defined by multiple factors including: impact to citizen services, potential loss of revenue to the state, potential increase of cost to the state, legislative mandates, or, potential negative impact and visibility of project failure. H = High Risk A = Medium Risk or L = Low Risk work effort.
"Project Assumptions:" Additional project assumptions, constraints, dependencies, and concerns that were not identified in the Project Proposal Estimating Assumptions noted above should be clearly defined on the bottom of page 4 in the "Project Assumptions" section. In addition, "Project Proposal Estimating Assumptions" with "OTH" (Other) as the response should be clarified in this section.
Estimates should be provided at many points throughout the system development life cycle. Reestimation, or the review and validation of the current estimate, should occur as a key project milestones using the estimating baseline, past performance, and changes in project assumptions to refine and adjust project estimates. Even with no change in project assumptions or scope, estimates should be reviewed periodically and tracked against actual performance.
VI.
Quality and Measurement Objectives
Since the objective of the estimating work bench is to provide a time and cost estimate, with known project risks and assumptions, the quality goal of all formal estimates is plus or minus 10% of the estimate with the stated degree of precision taken into account.
VII.
Estimate Utilization
Page 14 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Although the Project Proposal Estimate form is not required, it is suggested that the form be used as a work sheet to create all sizing, approximations, and estimates. Automated estimating and project planning tools (e.g., KnowledgePLAN, ABT Bridge Modeler, SLIM) have their own estimating and documentation system. However, the Project Proposal Estimate form is an excellent tool for the documentation of most project sizings and strategic planning approximations.
VIII. Compliance Compliance to the IRMC policy, standards, and procedures for estimating costs and delivery dates will be verified through the third party independent quality assurance review process. Compliance will be measured to process assurance objectives (conformance to IRMC policy requirements) and product assurance objectives (validity and integrity of sizing, approximation, or estimate data at the project level).
Attached, as Appendix A, is a visual representation of the Estimating Costs and Delivery Dates process workbench. Attached, as Appendix B, is a detailed "play script" of tasks associated with navigation of the Project Proposal Estimate form. Finally, attached as Appendix C is a copy of the Project Proposal Estimate form.
Page 15 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
Appendix A: Visual Representation of the Project Estimating Process (Work Bench Flow Chart)
PLAN | | | | | | | | | | | | | | | v Identify purpose of estimate Define degree of accuracy required Define estimating approach Review historical data base
INPUT -------------------------------->
Estimating Requirement
P R O C
DO | E | | S | | S | | | | | | | | | | v OUTPUT <------------------------------- ACT
Review Estimating Procedures Determine documentation format Assess complexity Identify estimating factors Identify estimate assumptions Identify project risks Identify project constraints Identify project dependencies Determine work effort Determine lapsed time Determine project cost
Completed Estimate
Define quality objectives Define documentation mechanism Define estimation validation process Define degree of preciseness Develop total project estimate Complete Project Proposal Estimate Obtain IT estimate approval Document project estimate Forward estimate to requester Obtain requester estimate approval Add data to database Verify performance to estimate
Page 16 of 21
02/13/03 9:12 AM
_____________________________________________________________________________ Appendix B: Tasks Associated with the Project Proposal Estimate Form (Play Script)
RESPONSIBLE PARTY
TASK
TASK DESCRIPTION
1 2 3 4 5 6 7 8 9 10
Requester Agency IT Requester/ Estimator Requester/ Estimator Requester/ Estimator Requester/ Estimator Estimator Estimator Estimator Estimator
Contact agency IT with a project estimating requirement. Assign a resource to complete the project estimate. Define what the estimate will be used for. Determine the degree of estimate preciseness required. Define project estimating assumptions. Determine estimate documentation format. Define estimating approach (tool, technique, methodology). Review Procedures for Estimating Costs and Delivery Dates. Review Project Proposal Estimate form. Complete the Project Proposal Estimate form project assumptions. Complete the Project Proposal Estimate form cost estimates. Review the proposed estimate. Finalize the proposed estimate. Approve the project estimate for cost and delivery dates. Forward the completed estimate to the requester. Approve the project estimate for cost and delivery dates. Determine estimate validation and update process. Add approved estimate to agency database. Verify actual performance to approved estimate.
11 12 13 14 15 16 17 18 19
Estimator Estimator/Agency IT Estimator Agency IT Estimator Requester Estimator/ Requester Agency IT Agency IT
Page 17 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
Project Name: Estimator's Name: Revision Number: Appendix C Sponsor's Name: Baseline Estimate Date: Revision Date: Estimated Direct Effort Hours Project Initiation Project Monitoring and Control Software Quality Management Concept Exploration System Allocation Requirements Design Implementation Installation Operation and Support Verification and Validation Configuration Management Documentation Development Training Staff Training User Training __________ (A.14) __________ (A.15) __________ (A.1) __________ (A.2) __________ (A.3) __________ (A.4) __________ (A.5) __________ (A.6) __________ (A.7) __________ (A.8) __________ (A.9) __________ (A.10) __________ (A.11) __________ (A.12) __________ (A.13)
Other _____________________________________ __________ (A.16) ___________________________________________________________________________________ Total Estimated Direct Effort Hours (A = Sum of A.1 through A.16) Estimated Indirect Effort Hours __________ (A)
Page 18 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
___________________________________________________________________________________ Total Estimated Direct Effort Hours (A on page 1) = ____________ _____% Change Percentage (Project scope changes) _____% Communication Percentage (Team meetings, status meetings) _____% Overtime Percentage (Scheduled overtime) _____% Project Management Percentage (Project planning activities) _____% Rework Percentage (Defect Rate) _____% Overhead Percentage (Indirect Charges, occupancy) _____% ________________________________ (Other indirect charges - specify) __________ (B.1)
__________ (B.2)
__________ (B.3)
__________ (B.4)
__________ (B.5)
__________ (B.6)
__________ (B.7)
Total Estimated Indirect Effort Hours (B = Sum of B.1 through B.7)
__________ (B)
Total Estimated Effort Hours (C = A + B) Productivity Factors Available hours per week Number of Developers Performance Percentage
___________ (C)
_______ (D) _______ (E) _______% (F)
Project Duration in Weeks (Lapsed Time)
(G = C / (D * E * F))
________ (G)
____________________________________________________________________________________ Estimated Project Cost (in dollars)
Page 19 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
Estimated Labor Cost (Total Estimated Effort Hours (C) * Cost Allocation Rate) Note: Cost Allocation Rate used was $___________ Projected Hardware Cost (Acquisition of new equipment) Projected Software / Middleware Cost (COTS, Architecture) Projected ITS Cost (Include CPU, DASD, transaction usage, anticipated client usage) Projected Indirect Billing Cost (Include printing operations, scheduling and control, etc.) Projected Travel Cost (Include travel expenses, conferences, etc.) Other Administrative Cost (Include office supplies, etc.) ___________________________________ (Other charges - please specify) $____________ (H)
$____________ (I)
$____________ (J)
$____________ (K)
$____________ (L)
$____________ (M)
$____________ (N)
$____________ (O)
Estimated Project Cost (P = H+I+J+K+L+M+N+O) Percentage Degree of Preciseness - ______%
$____________ (P) + ______% (Q)
** NOTE: Proposed estimates are based on project assumptions specified on page 4 ** Approval: ______________________________________ Date:___________
Accepted by: ____________________________________
Date:___________
Accepted by: ____________________________________
Date:___________
____________________________________________________________________________________
Page 20 of 21
02/13/03 9:12 AM
_____________________________________________________________________________
Project Proposal Estimating Assumptions
Type of Estimate: ________________________ Project Type: ____________________________ Project Platform: _________________________ Development Approach: ___________________ Project Size: _____________________________ SDLC Tool: _____________________________ User Involvement: ________________________ Development Team Skills: _________________ Clarity of Project Requirements: _____________ Extended Team Complexity: ________________ Technology Availability: ___________________ Degree of User Acceptance Testing: __________ Training Requirements: ____________________ Funding Availability: ______________________
Estimating Method: _______________ Project Driver: ____________________ Quality Concern: __________________ Schedule Concern: ________________ Cost Concern: ____________________ Function Complexity_______________ Function Stability: _________________ Availability of Resources: ___________ Management Focus: _______________ Responsibility Definition: ___________ Technology Experience: ____________ Complexity: ______________________ Documentation: ___________________ Project Risk: _____________________
Project Assumptions (dependencies, constraints, concerns, and issues):
Page 21 of 21
02/13/03 9:12 AM

Project Estimating Procedures

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Project Estimating Procedures

Caricato da

Copyright:

Formati disponibili

Information Resource Management Commission (IRMC) Procedure for Estimating Costs and Delivery Dates

Effective Date: 04/06/1999 Revision Date: 02/04/2003 ___________________________________________________________________________________________

_____________________________________________________________________________ IV. Procedure Definitions

_____________________________________________________________________________ A. Estimate Header Information (page 1)

Estimated Direct Effort Hours (page 1)

_____________________________________________________________________________ C. Estimated Indirect Effort Hours (page 2)

Total Estimated Effort Hours (page 2)

Project Duration in Weeks (page 2)

Estimated Project Cost (page 3)

Percentage Degree of Precision (page 3)

Project Proposal Estimating Assumptions (page 4)

Quality Concern: H = High A = Medium L = Low

Schedule Concern: H = High A = Medium L = Low

Cost Concern: H = High A = Medium L = Low

Quality and Measurement Objectives

DO | E | | S | | S | | | | | | | | | | v OUTPUT <------------------------------- ACT

Total Estimated Indirect Effort Hours (B = Sum of B.1 through B.7)

_______ (D) _______ (E) _______% (F)

Project Duration in Weeks (Lapsed Time)

____________________________________________________________________________________ Estimated Project Cost (in dollars)

Estimated Project Cost (P = H+I+J+K+L+M+N+O) Percentage Degree of Preciseness - ______%

$____________ (P) + ______% (Q)

Accepted by: ____________________________________

Accepted by: ____________________________________

Project Assumptions (dependencies, constraints, concerns, and issues):

Potrebbero piacerti anche

___ (D) _ (E) _____% (F)

$______ (P) + % (Q)