project estimating procedures

8/3/2019 Project Estimating Procedures

1/21

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

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

P:\IRM\Private\QA\ESTIMATE\PROCEDURES.DOC Page 1 of 21 02/13/03 9:12 AM

I. Purpose

The "Information Resource Management Commission (IRMC) Procedure for EstimatingCosts and Delivery Dates" is written to provide agencies with a consistent, predictable,repeatable, and measurable process to ensure that project estimates are complete, accurate, anddefensible. Also, this document is designed to provide the project manager (developer) and theproject sponsor (client) with detailed instructions on how to comply with the "InformationResource Management Commission (IRMC) Standard for Estimating Costs and DeliveryDates."

The purpose of the IRMC Procedure for Estimating Costs and Delivery Dates is to ensure theprompt and efficient capture, tracking, analysis, and response to client requests for agencyinformation technology (IT) estimating services. The Project Proposal Estimate form (sampleattached as Appendix C) is a structured vehicle and method of requesting and providingestimating service to project sponsors.

This procedure will detail a proposed project estimating process "work bench" that can be used toorganize, 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 post-development 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 agencyinformation 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 aportfolio of estimating techniques which may be used by agency personnel to satisfy estimatingrequests for IT products and services.


2/21


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 andending date with identified deliverables of either products or services. The four (4) projectcategories 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 todetermine 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 clientswith various types of project estimates. Estimating will occur at different points within theproject 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 workto 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 decisionssuch as: initiate the project or determine another direction, purchase the system versus build thesystem. 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 andthe confidence level of sizing estimates will vary greatly based on previous experience andspecific 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 theleast precise of all estimates and should only be used in pre-development process planningactivities or in the strategic planning process.


3/21



_____________________________________________________________________________


Approximations are project assessments of costs and delivery dates. Approximations aredeveloped 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 inthe 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 todetermine general project completion time frames. Approximations are not as precise asestimates but are more precise than a sizing.

Estimates are detailed project phase projections of resource assignment, delivery dates, andbudgeted 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 monitorproject 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 shouldbe used as project commitments and plan versus actual performance measurements. Agencies

should use estimates to determine specific development phase, or activity, completion timeframe and cost.

V. Field Definitions

The Project Proposal Estimate form is composed of nine (9) major sub-sections. These sub-

sections 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).


4/21



_____________________________________________________________________________


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 incrementedby 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 followingfour (4) questions are answered. The four key questions are:

1.) What will the estimate be used for?

2.) What degree of preciseness is required for the estimate (plus and minus what percentage)?3.) What are the project assumptions used to develop the estimate? and

4.) What estimating approach (tool, technique, or methodology) will be used to develop theestimate?

Once these four questions have been answered, the estimator may proceed with completing theestimating form.

B. Estimated Direct Effort Hours (page 1)

The Estimated Direct Effort Hours portion of the Project Proposal Estimate form is a costestimate in hours of the work to be performed. The categories correspond to the IEEE Standardsfor 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.


5/21



_____________________________________________________________________________


C. Estimated Indirect Effort Hours (page 2)

Based on the direct labor hours, estimates should be provided for indirect effort hours - factorsthat are common to all projects (e.g., change management, problem management, projectmeetings, 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 toperform 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.*). Thetotal of all estimated indirect hours should be summed and noted on page 2 line B - TotalEstimated 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 onpage 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 ofdevelopment 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 estimateofProject 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 Costsection provide the client with a dollar

summary of estimated project costs. Certain fields may be calculated (e.g., Estimated LaborCost 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.


6/21



_____________________________________________________________________________


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 andunder) 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 assumptionsdefined 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. Theestimator must sign the estimate form and the estimate must be accepted by both agency ITmanagement and the project sponsor, or designee.

I. Project Proposal Estimating Assumptions (page 4)

The Project Proposal Estimating Assumptions section is a detailed summary of projectassumptions 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 high-level 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.


7/21



_____________________________________________________________________________


Estimating Method:Methodology used to complete the estimate. Estimating methodologiesmay vary and might include:

INT = Intuitive estimating based on application knowledge and experience of theestimator.

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 remainingphases).

LOC = Lines of code (COCOMO tool).FPA = Function point analysis (IFPUG).

WAC = Weighted average calculation (Weighted Average Cost) of one optimisticestimate, 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 determiningproject complexity with estimates by phases.

BOT = Bottom-up estimating refers to task by task work break down structure estimatesadded up to provide a detailed overall estimate.

ITS = Iterative estimate based on task by task bottoms up estimates refined aftercompletion of each phase or check point by taking actuals for completed phases andestimating all other phases, orCON = Consensus of experts (Wide Band Delphi Technique) derived from brain

storming project estimates.CAS = Tool-based software estimate from CASE tools such as KnowledgePLAN, ABTBridge 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.


8/21



_____________________________________________________________________________


Project Driver: Project sponsor priority defined as:

T = TimeB = Budget orF = Function

Project Platform:

MF= MainframePC = Personal ComputerLN = Local Area NetworkWN = Wide Area Network

CS = ClientServer orOT - Other, please specify in "Project Assumptions" on page 4

Quality Concern:

H= HighA = MediumL = Low

Development Approach: Although the development approach may vary, and hybriddevelopment approaches may be used, the most common system development life cycle (SDLC)approaches are:

TRA = Traditional waterfall phased approachPRO = Prototype developmentRAD = Rapid application developmentSPL = Spiral developmentITD = Iterative development orOTH = Other, please specify in "Project Assumptions" on page 4.

Schedule Concern:



9/21



_____________________________________________________________________________


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 thefollowing characteristics:

- The work will be carried out by a single staff member within a time period offour 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 estimatingrequest,

- Examples of Category 1 projects would include hardware / software

configuration requests, packaged software installation that involve no codemodification, JCL changes, training requests, small consultation estimates, and

documentation requests.

CAT 2 projects are estimating requests involving minor analysis and programming andusually 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 andtesting, and diagnostic (debugging) requests.

CAT 3 projects are estimating requests that involve significant analysis, programming, ortesting and typically have the following characteristics:

- The project will utilize up to five staff and / or contractors within a period of sixmonths or less,

- There will be a formal project approval / budget authorization and project workplan,- 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


10/21



_____________________________________________________________________________


- Examples of Category 3 projects include packaged system installations requiringextensive 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. Theseprojects will involve significant analysis, design, programming, and testing, and usually

involve a high level of risk in implementation. Category 4 projects estimates have thefollowing characteristics:

- The project work will utilize five or more project staff and / or contractorswithin 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, orconsulting 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 planningcycle, and

- Examples of Category 4 projects include packaged system installations requiringextensive programming, interface code, and testing; extensive modifications to

existing systems, or the development of large new systems; and projects involving

new technologies.

Cost Concern:


"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".


11/21



_____________________________________________________________________________


Function Complexity:

S = Simple with no interface systemsA = Average with minimum (up to 2) system interfaces orC = Complex with multiple (more than 2) system interfaces and dependencies.

User Involvement:

H = Highly involvedA = Average involvement orL = No significant user involvement in the project

"Function Stability:"

H = High degree of function definition and understanding with minimal changes requiredprior to implementation.

A = Average, basic functionality is known but will have managed change control duringproject implementation orL = Low, functional requirements are not known and will change significantly

"Development Team Skills:"

S = Basic application development skills requiredA = 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 projectA = Medium availability of resources capable of completing the project orL = Low availability of in-house resources needed to complete the project.


12/21



_____________________________________________________________________________


Clarity of Project Requirements:"

H = High clarity in requirements definition, easily understood by agency IT and clearlydefined by the clientA = Average clarity, all function not clearly defined orL = Low clarity with a fuzzy definition of requirements where the impact is not clearlyunderstood 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 organizationA = Average IT and agency responsibility matrix orC = Complex multi-functional relationship with multiple agencies involved indevelopment, implementation, and support.

"Responsibility Definition:

S = Simple, clearly defined, and accepted project responsibilitiesA = Average responsibility matrix with some responsibilities understood but not clearlydefined nor accepted or

C = Complex matrix of responsibilities where responsibilities are not clearly defined norunderstood and accepted.

Technology Availability:

H = General high availability of all proposed technology tools and techniquesA = Availability of some technology tools and techniques orL = Low availability of required technology tools and techniques.

Technology Experience:


13/21



_____________________________________________________________________________


H = High level of experience using project tools and technologiesA = 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 requiredA = Average level of user acceptance testing required orL = Low level of user acceptance testing required.

Complexity:

H = High overall project technical complexityA = Average overall project technical complexity orL = Low overall project technical complexity

Training Requirements:

H = High level of user training requiredA = Average level of user training required orL = Low level of user training required.

Documentation:

H = High level of project documentation requiredA = Average level of documentation required orL = Low level of project documentation required.

Funding Availability:

Y = Yes, funding is available and committed by the sponsor, orN = No management commitment for funding of the project at this time.


14/21



_____________________________________________________________________________


"Project Risk: Overall project risk must be defined by multiple factors including: impact tocitizen 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 RiskA = Medium Risk orL = 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 thebottom of page 4 in the "Project Assumptions" section. In addition, "Project Proposal EstimatingAssumptions" 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. Re-

estimation, or the review and validation of the current estimate, should occur as a key projectmilestones 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 minus10% of the estimate with the stated degree of precision taken into account.

VII. Estimate Utilization


15/21



_____________________________________________________________________________


Although the Project Proposal Estimate form is not required, it is suggested that the form beused 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 ownestimating and documentation system. However, the Project Proposal Estimate form is anexcellent tool for the documentation of most project sizings and strategic planningapproximations.

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 policyrequirements) 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 withnavigation of the Project Proposal Estimate form. Finally, attached as Appendix C is a copy ofthe Project Proposal Estimate form.


16/21



_____________________________________________________________________________


Appendix A: Visual Representation of the Project Estimating Process (Work Bench Flow Chart)

INPUT --------------------------------> PLAN Identify purpose of estimate| Define degree of accuracy required| Define estimating approach

Estimating Requirement | Review historical data base||||||||

P ||

R | ReviewEstimating Procedures| Determine documentation format

O v Assess complexityIdentify estimating factors

C DO Identify estimate assumptions| Identify project risks

E | Identify project constraints| Identify project dependencies

S | Determine work effort| Determine lapsed time

S | Determine project cost

||||||| Define quality objectives| Define documentation mechanism| Define estimation validation processv Define degree of preciseness

OUTPUT


17/21



_____________________________________________________________________________


Appendix B: Tasks Associated with theProject Proposal Estimate Form (Play Script)

TASKRESPONSIBLE

PARTY TASK DESCRIPTION

1 Requester Contact agency IT with a project estimating requirement.

2 Agency IT Assign a resource to complete the project estimate.

3 Requester/ Estimator Define what the estimate will be used for.

4 Requester/ Estimator Determine the degree of estimate preciseness required.

5 Requester/ Estimator Define project estimating assumptions.

6 Requester/ Estimator Determine estimate documentation format.

7 Estimator Define estimating approach (tool, technique, methodology).

8 Estimator ReviewProcedures for Estimating Costs and Delivery Dates.

9 Estimator ReviewProject Proposal Estimate form.

10 Estimator Complete theProject Proposal Estimate form project

assumptions.

11 Estimator Complete theProject Proposal Estimate form cost estimates.

12 Estimator/Agency IT Review the proposed estimate.

13 Estimator Finalize the proposed estimate.

14 Agency IT Approve the project estimate for cost and delivery dates.

15 Estimator Forward the completed estimate to the requester.

16 Requester Approve the project estimate for cost and delivery dates.

17 Estimator/ Requester Determine estimate validation and update process.

18 Agency IT Add approved estimate to agency database.

19 Agency IT Verify actual performance to approved estimate.


18/21



_____________________________________________________________________________


Project Name: Appendix C Sponsor's Name:

Estimator's Name: Baseline Estimate Date:Revision Number: Revision Date:

Estimated Direct Effort Hours

Project Initiation __________ (A.1)

Project Monitoring and Control __________ (A.2)

Software Quality Management __________ (A.3)

Concept Exploration __________ (A.4)

System Allocation __________ (A.5)

Requirements __________ (A.6)

Design __________ (A.7)

Implementation __________ (A.8)

Installation __________ (A.9)

Operation and Support__________ (A.10)

Verification and Validation __________ (A.11)

Configuration Management __________ (A.12)

Documentation Development __________ (A.13)

Training

Staff Training __________ (A.14)

User Training __________ (A.15)

Other _____________________________________ __________ (A.16)___________________________________________________________________________________

Total Estimated Direct Effort Hours __________ (A)(A = Sum of A.1 through A.16)

Estimated Indirect Effort Hours


19/21



_____________________________________________________________________________


___________________________________________________________________________________

Total Estimated Direct Effort Hours (A on page 1) = ____________

_____% Change Percentage __________ (B.1)(Project scope changes)

_____% Communication Percentage __________ (B.2)(Team meetings, status meetings)

_____% Overtime Percentage __________ (B.3)(Scheduled overtime)

_____% Project Management Percentage __________ (B.4)

(Project planning activities)

_____% Rework Percentage __________ (B.5)(Defect Rate)

_____% Overhead Percentage __________ (B.6)(Indirect Charges, occupancy)

_____% ________________________________ __________ (B.7)(Other indirect charges - specify)

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

Total Estimated Effort Hours (C = A + B) ___________ (C)

Productivity Factors

Available hours per week _______ (D)Number of Developers _______ (E)

Performance Percentage _______% (F)

Project Duration in Weeks (Lapsed Time) (G = C / (D * E * F)) ________ (G)

____________________________________________________________________________________

Estimated Project Cost (in dollars)


20/21



_____________________________________________________________________________


Estimated Labor Cost $____________ (H)(Total Estimated Effort Hours (C) * Cost Allocation Rate)Note: Cost Allocation Rate used was $___________

Projected Hardware Cost $____________ (I)(Acquisition of new equipment)

Projected Software / Middleware Cost $____________ (J)(COTS, Architecture)

Projected ITS Cost $____________ (K)(Include CPU, DASD, transaction usage, anticipated client usage)

Projected Indirect BillingCost $____________ (L)(Include printing operations, scheduling and control, etc.)

Projected Travel Cost $____________ (M)(Include travel expenses, conferences, etc.)

Other Administrative Cost $____________ (N)(Include office supplies, etc.)

___________________________________ $____________ (O)(Other charges - please specify)

Estimated Project Cost (P = H+I+J+K+L+M+N+O) $____________ (P)

Percentage Degree of Preciseness - ______% + ______% (Q)

** NOTE: Proposed estimates are based on project assumptions specified on page 4 **

Approval: ______________________________________ Date:___________

Accepted by: ____________________________________ Date:___________

Accepted by: ____________________________________ Date:___________

____________________________________________________________________________________


21/21



_____________________________________________________________________________

Project Proposal EstimatingAssumptions

Type of Estimate: ________________________ Estimating Method: _______________

Project Type: ____________________________ Project Driver: ____________________

Project Platform: _________________________ Quality Concern: __________________

Development Approach: ___________________ Schedule Concern: ________________

Project Size: _____________________________ Cost Concern: ____________________

SDLC Tool: _____________________________ Function Complexity_______________

User Involvement: ________________________ Function Stability: _________________

Development Team Skills: _________________ Availability of Resources: ___________

Clarity of Project Requirements: _____________ Management Focus: _______________

Extended Team Complexity: ________________ Responsibility Definition: ___________

Technology Availability: ___________________ Technology Experience: ____________

Degree of User Acceptance Testing: __________ Complexity: ______________________

Training Requirements: ____________________ Documentation: ___________________

Funding Availability: ______________________ Project Risk: _____________________

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

project estimating procedures

Documents