Escolar Documentos
Profissional Documentos
Cultura Documentos
2/26/2013
Estimating Templates____________________________________________________14
General Purpose Templates____________________________________________________14
Staff and Duration Estimating Template...........................................................................................14 Travel Expenses Template.................................................................................................................14 Requirements/BAA Proportional Estimate Projection Template......................................................14
2/26/2013
Estimating Guidelines____________________________________________________17
Project-Wide Guidelines_______________________________________________________17 ASPIRE Phase Guidelines_____________________________________________________19
Vision and Strategy (ETP)___________________________________________________________19 Business Area Architecture (Requirements/BAA)_________________________________________20 Development______________________________________________________________________21 Integration________________________________________________________________________21 Deployment_______________________________________________________________________21
Specialty Areas______________________________________________________________22
Development______________________________________________________________________22 Package Based Development (PBD)..................................................................................................22 Package Evaluation and Selection (PES) Sub-Phase.........................................................................24 Iterative Custom Development (ICD)................................................................................................26 Accelerated Application Development (X/AD).................................................................................33 Organizational Change______________________________________________________________36 Technical Infrastructure_____________________________________________________________38 Critical Computer Resources and Facilities Infrastructure__________________________________38
Appendices_____________________________________________________________40
Estimating Templates_________________________________________________________40 Estimating Template User Guides_______________________________________________40
Staff and Duration Estimating Templates_______________________________________________40 Travel Expenses Template___________________________________________________________40 Requirements/BAA Proportional Estimate Projection Template______________________________40 Package-Based Development (PBD) Estimating Template__________________________________41 Matrix-Based Iterative Custom Development (ICD) Estimating Template______________________42 Accelerated Application Development (XAD) Estimating Template__________________________44 Communication Event Estimating Template_____________________________________________45 Stakeholder Group Estimating Template________________________________________________46
2/26/2013
Estimating Approaches
There are two basic approaches for determining the estimates for a given component of a project, topdown and bottom-up. IT Services highly recommends that you estimate a project using both of these approaches. A top-down estimating approach takes an estimate for an entire project and breaks it down
2/26/2013
2/26/2013
Bottom-Up
Enforces relatively thorough analysis before estimation. Identifies uncertainties in developers knowledge of system requirements or proposed solution.
Estimating Techniques
The following estimating techniques fit into either the top-down or bottom-up approach. No one estimating technique is ideal for all situations; each has its own strengths and weaknesses. When estimating a project, you need to decide which technique is appropriate and what adjustments, if any, are needed.
Ballpark Estimating
With this estimating technique you use a combination of time, effort, peak staff, and derived from the QSM SLIM completed projects database. Each row represents a consistent set of estimates that may be determined based on any one of the variables estimated using expert judgment. This technique can be used at any point in the lifecycle. It can be used early in the lifecycle and when no historical information is available. Once the estimate is developed, a comparative estimate can be
2/26/2013
2/26/2013
Comparative
Using this estimating technique, you compare the project at hand, the target project, with other projects similar in scope and type to produce an estimate. The comparison is normally performed at a high-level with little reference to detail. This technique relies heavily on the experience of the estimators and their ability to gauge the target project in relation to the comparative data available. For example you have been asked to estimate the custom development for a new telecommunications system. You also happen to know of a similar type of project that was also custom developed. Since this reference project covered roughly 50% of the functionality needed by the new system, you could develop a comparative estimate for the new telecommunications systems by doubling the actual effort from your reference project. You could even add an additional percentage of effort to account for some of the unknowns in the new system. The comparison does not have to be at a project or phase level. You can use this technique for lower-level tasks such as developing a reporting sub-system or a customer maintenance window. This technique is useful as a sanity check for an estimate produced by another method. It can also be useful for estimating low-level components such as documentation, printer volume, processor capacity, or programming a specific system component. The major weakness of this technique is that a project is not thoroughly assessed. Therefore, it should be used only if time is limited or a relatively large uncertainty in the estimate can be tolerated. This technique also requires some type of historical data to compare against.
Expert Judgment
This technique relies on the extensive experience and judgment of the estimator to compare the requirements for the component being estimated against all projects in his/her previous experience. It differs from the comparative technique in that the reference projects are not explicitly identified.
Proportional Estimating
With this estimating technique you use the size of one component to proportionally estimate the size of another. For example, Quality Assurance might be estimated as 3% of the total project effort; the design effort might be estimated as 40% of the coding effort; the number of printers might be estimated as one for every 6 users. Previous personal experience or estimating guidelines can help provide these proportionality factors. This technique is very effective when used appropriately, when the estimated value really does depend proportionally on another factor. However, it should not be used as a crutch to pass the estimating responsibility on to some other component. Using this technique will magnify estimating errors being made elsewhere. Proportional estimates can be used in combination with other estimating techniques. For example, after using widget counting to derive the estimate for the Requirements phase of a project and then used proportional factors to estimate the Design, Code/Unit Test, System and Integration Testing, Implementation, and Deployment phases of the project.
Widget Counting
Using this estimating technique, you identify project characteristics that can be counted and that are performed on a recurring basis (the widget), estimate the effort for each type of widget, and determine the total effort by applying these estimates against the total number of widgets. Typical widgets may be
2/26/2013
Function points are viewed from the perspective of the system boundary and are comprised of the following types: InputAny data or control information provided by the user that adds or changes data held by the system. An input can originate directly from the user or from user-generated transactions from an intermediary system. Inputs exclude transactions or files that enter the system as a result of an independent process. OutputAny unique unit of data or control information that is procedurally generated by the system for the benefit of the user. This would include logical units forming part of printed reports, output display screens, audit trails, and messages. InquiryEach unique input/output combination, in which the online user defines an inquiry as input and the system responds immediately with an output. An inquiry is distinct from an output in that it is not procedurally generated. The result of an inquiry may be a display/report or a transaction file that is accessible by the user. Logical Internal FileAny logical group of data held by the system. This includes database tables and records on physical files describing a single logical object. A logical file may span many physical files (e.g., index, data, and overflow). However, it is treated as a single logical internal file for sizing purposes. External Interface FileEach logical group of data that is input to or output from the system boundary to share that data with another system. Advantages for using Function Point Analysis include:
The project is viewed from the perspective of the user rather than the developer, that is, in terms of user functions rather than programs, files, or objects. The estimates can be developed from knowledge of the requirements without a detailed design solution being known. This provides for a level of independence from the specific hardware platform, languages, developers skill level, and the organizations line of business.
2/26/2013
The use of Function Point Analysis is accepted internationally. There is also a users group, International Function Point Users Group (IFPUG), which has established standards to help encourage consistency in counting function points.
This approach does not accurately estimate systems that are largely algorithmic such as military systems, space systems, robotics, process control, and middleware. Function Points can be complicated to administer. Formal training is needed before you can consistently count, and therefore track, function points. The use of function points is not widely accepted within IT Services. As a result, we have not gathered any estimating guidelines or metrics for function point estimating. Since the concept of Function Point Analysis was developed with older technologies and development approaches, it is not certain how well this concept applies to newer technologies and development approaches such as object-oriented development. However, variations of Function Point Analysis are being developed to address the newer technologies and development approaches.
Feature Points
This estimating technique is an extension to the function point analysis technique. It involves adding a number of algorithms with an average complexity weight and changing the function point weighting in other areas. For typical management information systems, there is little difference in the results between Function Points and Feature Points, both techniques result in nearly the same number of points. For real-time or highly algorithmic systems, however, the results can be significantly different between these two techniques. The Function Point count for such systems totals only 60 to 80 percent of the Feature Point count. Note: Before using this estimating technique, you should read one of the published books on this subject.
10
2/26/2013
Technique Comparison
The following table highlights the strengths and weaknesses of these estimating techniques: Estimation Technique Comparative Strengths Estimate can be very accurate if a suitable analogy can be identified.
Weaknesses Historical data repository required. Often difficult to find comparable projects. Must be verified by another method. High risk; may not be repeatable by anyone other than the expert. Single data point. Requires previous personal experience or experience-based guideline metrics for proportionality factors. Can magnify estimating errors made in other areas. Magnifies size errors if widget effort estimates are incorrect. Assumes effort to develop system is proportional to number of widgets, even though system is not necessarily made up purely of widgets. Does not accurately estimate systems that are largely algorithmic such as military systems, space systems, robotics, and process control. Does not have overall acceptance within IT Services. Can be complicated to administer. Requires formal training.
Expert Judgment
Estimate can be extremely accurate. Identifies areas where requirements clarification is needed. Identifies requirements tradeoffs.
Proportional
Effective when estimated value really does depend proportionally on another factor (e.g., software management, quality assurance, configuration management).
Widget Counting
Feature Point
Well suited for standard Management Information System projects with little internal processing complexity, especially those using 4GL, report writer, or CASE tool environments. Project viewed from user, not developer, perspective (e.g., user functions rather than programs, files). Estimates can be developed from knowledge of requirements without a detailed design solution being known. Provides independence from hardware platform, languages, developers skill at code efficiency, business of organization. Consistency encouraged through established international standards for function point counting. Same strengths as Function Point Analysis, with added benefit of accounting for algorithms and internal processing complexity.
Does not yet have overall acceptance. Can be complicated to administer. Requires formal training.
11
2/26/2013
Estimating Techniques
Comparative Proportional Expert Judgement Widget Counting Function Point Analysis Feature Point Analysis
Vision & Stategy, & ETP Business Area Architecture Development Integration Deployment Development Organizational Change Technical Infrastructure Facilities Infrastructue Year 2000 Development Coordination Project Management Program Management
Not Recommended
Recommended
12
2/26/2013
CHECKPOINT/KnowledgePLAN Overview
CHECKPOINT, from Software Productivity Research Inc., is a knowledge-based software management tool that can analyze, evaluate, and store data about your development projects. CHECKPOINT integrates sizing, planning, scheduling, estimating, quality estimating, measurement, risk analysis, value analysis, and technology assessment. It offers the capability to: Predict source code size. Estimate the cost of developing systems as well as the cost of developing specifications and user documentation. Estimate projects using a knowledge-base of over 4,700 software projects. Measure all aspects of a software project at a user-defined level of granularity. Assess a wide range of software attributes against industry standards for cost, quality, schedules, and productivity. Aggregate data across selected projects. Perform side-by-side comparisons of project versions, different projects, or a project against other established benchmarks. Perform what-if analysis for a variety of variables including CASE tools, languages, skills, and methodologies.
13
2/26/2013
Estimating Templates
There are a variety of estimating templates or spreadsheets being used throughout the organization to assist with our project estimating efforts. Following is a high-level summary of the templates that the Estimating and Metrics team have obtained, created, or modified. The actual spreadsheets have been attached as separate files. Detailed instructions for using these spreadsheets are located in the appendix.
Development
A number of estimating templates have been collected that support the Development phase of ASPIRE. Please refer to the Development estimating templates for a complete list.
Integration
Specific estimating templates have not been developed for this phase. The various Development estimating templates generally use a proportional estimating factor for this phase. The general Staff and Duration estimating template can also be applied to this phase.
14
2/26/2013
Organizational Change
Communication Event Estimating Template
This estimating template assists in estimating the effort to design and deliver communication events using the calculations described in the Organizational Change estimating guidelines; these guidelines are provided later in this document. Two estimating options are included in this template.
15
2/26/2013
Technical Infrastructure
Specific estimating templates have not been developed for this specialty area.
Facilities Infrastructure
Specific estimating templates have not been developed for this specialty area except for Critical Computer Resources.
16
2/26/2013
Facilities Infrastructure
Development
Estimating Templates:
Requirements/Proportional Package Based Dev Iterative Custom Dev Accelerated Application Dev Ballpark Estimating Proportional Percentage ... TBD ...
Recommended
Not Recommended
Estimating Guidelines
Project-Wide Guidelines
The following estimating guidelines can be applied across all phases of a project. Refer to the Estimating Process Guide for additional guidelines. Use at least two, and preferably three, estimating approaches or techniques when estimating your project. Using multiple approaches will help ensure a higher level of confidence in the final estimates. Your estimate should include at least one top-down and one bottom-up approach. On larger scale estimating efforts, you will often need to make assumptions to fill the gaps in the information needed to create the estimate. Be sure to document any assumptions, constraints, or risks that you identify during this process in the Estimating Notebook. These items must also be incorporated into the projects Statement of Work. To estimate effectively, you need to understand the scope, requirements, and the approach. These should be documented in your Statement of Work. You will also need to identify any of the surrounding activities or components. For example, if you are trying to estimate an Enterprise Transformation Plan, you should take into account the effort to produce the final deliverables as well as the workshops, interviews, travel, project management time, and delivery assurance. (Note: In most cases you will be developing the Statement of Work at the same time you are developing your estimates. There will be cases where your estimating process requires that you update your Statement of Work and visaversa. Although these are often done concurrently, an initial draft of your Statement of Work, especially the scope and approach sections, will be a valuable source of input for your estimating process.)
17
Development Coordination
Business Architecture
Project Management
Deployment
Program Management
Integration
Process Initiative
2/26/2013
18
2/26/2013
Estimating Technique Guide ASPIRE Phase Guidelines Vision and Strategy (ETP)
General Information Several interviews with project teams indicate that the "soft deliverables" associated with an ETP allow a fair amount of flexibility in the duration of the study. Client expectations must be carefully managed as to the level of detail that will be provided as a result of the study. If expectations are not properly managed, significant cost overruns and loss of credibility are likely, even for a relatively small project such as an ETP. Another critical success factor is the staffing. A good client relationship person is key, as well as one or two solid Business Analysts and a good Technical Architect who can take a pragmatic approach and make fact-based recommendations. Estimating Techniques, Tools, and Templates Recommended estimating techniques include comparative and expert judgment. You can also use a proportional or widget counting technique to get an alternative estimate. None of the estimating tools that we have used address this phase of a project. The only estimating template that we currently have available for an ETP is the general staff and duration estimating template. Estimating Rules of Thumb (Note: The following estimating rules of thumb have been collected from a variety of sources including an Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field visits. Not all of these have been confirmed or validated.) Following are some rules of thumb that have been used on prior projects.
It takes four people approximately six weeks to complete an ETP study. Plan on one to two days per page for preparing the final documentation. The total cost for an ETP seems to be in the $50,000 to $350,000 range. Assuming a $200/hr billing rate this would translate to 250 to 1,750 hours.
Cautions Following is a list of potential gotchas that could impact your ETP estimates. Review these and adjust your estimates, assumptions, or risk factors accordingly.
At the outset of the project, client expectations must be carefully managed as to the level of detail that will be provided as a result of the study. If expectations are not properly managed, significant cost overruns and loss of credibility are likely, even for a relatively small project such as an ETP. The primary deliverable is a prioritized listing of future steps to achieve the Vision set by the study. The time to develop this plan is often underestimated. The answer usually does not "fall out" from the work done during the study. Manage client expectations on the length of the document to be presented and the depth to which it will extend. Will we estimate IT Services involvement or leave the numbers "generic"? Will dollars be associated with the estimates? Will the estimates be considered "IT Services bid" for the work? In the likely event that the plans for the future studies become budgeted numbers for the client, we must realize that IT Services will need to be prepared to do the work for those estimates. A plan that we cannot live with surely is one the client cannot live with.
19
2/26/2013
How many user representatives will be involved with the Requirements/BAA effort? How many representatives will be providing requirements? How many interviews will you conduct? Include interviews at the executive level as well as firstlevel management. How many departments or locations will be involved? What is the clients overall organizational structure? For example is the clients organization largely regulatory, multinational, multidivisional, centralized, or decentralized? What is the scope baseline as defined by each of the six domains of change? What deliverables is the client expecting to be delivered? What is the expected level of detail for these deliverables? How many process threads will you be addressing? Is the client looking for a business process redesign or a business process improvement? How many conceptual data entities are expected to be involved? How many workshops are you expecting to conduct? How many individuals will be attending these workshops? What are the time box assumptions for each workshop? How many best practice interviews are you expecting to conduct? How many legacy systems are involved? Will customer, supplier, or competitor surveys be conducted? And if so, how many customers, suppliers, or competitors will be targeted? Do we have already identified an industry or business best practice for this type of client? Will there be a final presentation? Who will do the final sign-off; I/S or the business users? How many individuals will be reviewing or approving deliverables? Will you need to create a business case for action? Will the client be using a value discipline? Has this already been established? How many alternative architectures is the client expecting?
Estimating Techniques, Tools, and Templates Recommended estimating techniques include comparative and expert judgment. You can also use a proportional or widget counting technique to get an alternative estimate. Possible estimating tools include Ballpark, QSM Slim, and Proportional Percentage. The only estimating template we currently have available for a Requirements//BAA is the general staff and duration estimating template. Estimating Rules of Thumb (Note: The following estimating rules of thumb have been collected from a variety of sources including an Estimating Workshop that was conducted in April, 1996, prior experiences, and from our various field visits. Not all of these have been confirmed or validated.) Following are some rules of thumb that have been used on prior projects. Since the scope and depth of the final deliverable for a Requirements/BAA can vary significantly from project to project; you will need to adjust your estimates based your specific project. The following staff size/ project duration have been used on prior Requirements/BAA efforts: Six people for five months
20
2/26/2013
Note: If you have already provided estimates for subsequent phases, knowing the estimating drivers that were used for these later phases will also help you to identify the overall impact of the scope changes.
Development
Refer to the Development estimating guidelines for each of the specific Development paths.
Integration
Specific estimating guidelines have not been developed for this phase at this time. During our field support visits, we generally used a proportional factor for this phase. Other estimating options include using a staff and duration model or basing the estimates on the number of test scenarios that need to be executed.
Deployment
Specific estimating guidelines have not been developed for this phase at this time. During our field support visits, we generally used a proportional factor for this phase. Other estimating options include using a staff and duration model or basing the estimates on the number of deployment sites.
21
2/26/2013
Estimating Technique Guide Specialty Areas Development Package Based Development (PBD)
General Information The following estimating guidelines apply to the entire PBD specialty area. More specific estimating guidelines have also been included for the Package Evaluation and Selection (PES) sub-phase. The following questions can help you to size your overall PBD effort. Have a clear definition of an enhancement, a configuration, and a modification. An enhancement involves making a fix using the tools provided by the vendor. A configuration involves setting a software parameter as intended. A modification is a change to the core software code. As a general rule, Do Not Make Modifications! Does the package include any modules that are provided by ancillary vendors? Will the project include a Requirements/BAA? What is the extent will the business processes change; is the client expecting a process improvement or a reengineering of its business processes? Is a Technical Infrastructure included? Will the project include PSD through implementation? Does the project scope include any production support? Any Training? What is the messaging infrastructure (mainframe component)? Does the project scope include data mapping? Does the project scope include Organizational change for IS or the business community? Does the project scope include a gap analysis? What percentage of change is the client expecting? Will the project team have direct or intermediary contact with the users and decision makers? How involved will the user community be? Will IT Services have overall project control or will we be shadow-managing? Does the project scope include a pilot? Does it include a roll-out? What other tools (IT or project management) will be required for this project? How much experience does the client have with the proposed platform? How sophisticated is the client with this platform? Additional support, policies, and procedures may be required. How will the application or data be distributed across locations? Will the application or data be distributed over time? Who (IT Services or client) will be responsible for managing the software vendor? Estimating Techniques, Tools, and Templates Estimating techniques that apply to a PBD effort include comparative, expert judgment, and widget counting. All of the estimating tools discussed in the prior section provide some level of support for a package-based development approach. CA-Estimacs contains a packaged-based lifecycle model; however, we have had minimal success with using CA-Estimacs to estimate this type of a project. Checkpoint applies mainly to any proposed enhancements and is not recommended for a package-based development effort. We have developed a package-based estimating template that can support a single or multiple applications.
22
2/26/2013
23
2/26/2013
24
2/26/2013
25
2/26/2013
Following are some general PowerBuilder/ PowerTools metrics. These hours are for coding and unit testing 2-tier applications; you will need to adjust these for more complex 3-tier applications. These estimates are based on an existing, approved prototype. For estimates in excess of 88 hours, try to breakdown into simpler tasks in order to accurately estimate the progress of this task. Simple: Medium: Complex: 24 - 32 hours 40 - 48 hours 80 - 88+ hours
Note: Simple Window: Contains 1-2 simple objects such as a drop down data window or single line edits. There can be a simple query done in this window that does a select from a single table. Many of the data maintenance windows fall into this category.
26
2/26/2013
Note: Simple Procedure: Contains a single simple query. Does not contain any logic. Medium Procedure: Contains 1-2 transactions, simple logic within the stored procedure, simple cursor manipulation, simple exception handling. Complex Procedure: Contains complex program logic, complex data manipulation, multiple table (4 or more) joins in the logic, and has multiple cursor management with in the stored procedure. This stored procedure can have multiple transactions processing within the procedure, complex queries, inserts, updates and deletes from the database, and complex exception handling.
27
2/26/2013
The following metrics can be used to determine the effort for creating a logical data model: Four attributes per hour Five relationships per hour One entity per hour Following are some general conversion metrics. These estimates include the design, code, and unit testing for each conversion program. The actual conversion effort is not included. Simple: Simple-Medium: Medium: Medium-Complex: Complex: 120 hours 160 hours 200 hours 280 hours 400 hours
Note: Simple Conversion: A simple extract and post program. Expect that less than 10% of the conversion programs to be classified in this category. Simple-Medium Conversion: Expect approximately 10% of the conversion programs to be classified in the category. Medium Conversion: Expect to have approximately 10 - 20% of the conversion programs to be classified in this category. Medium-Complex Conversion: Expect to have approximately 20 - 50% of the conversion programs to be classified in this category. Complex Conversion: Expect to have over 50% of the conversion programs to be classified in this category. Following are some guidelines for developing Oracle Forms. These following estimates are for Forms 4.0 and they assume that the form has been generated through Designer/2000. (If the form was created manually, and additional 12 to 20 hours should be added to the estimates depending on the number of blocks, fields, canvases, and list values contained in the window.) Simple: Medium: Complex: Very Complex: 24 hours 40 hours 64 hours 104 hours
Note: It is not certain whether these estimates only include just the development of these forms or whether these estimates include development and unit testing. Simple: A simple form is one that contains only one block and requires few edits or validations.
28
2/26/2013
Note: It is not certain whether these estimates only include just the development of these reports or whether these estimates include development and unit testing. Simple: A simple report is one that contains only one query and requires little formatting. Medium: A medium report is one that contains two or three queries and a moderate amount of formatting. Complex: A complex report is one that contains two or more queries and requires a substantial amount of formatting. Very Complex: A very complex report is one that contains two or more queries and requires a significant amount of formatting. Following are some guidelines for developing Oracle Zooms. The following estimates cover any custom zooms written to allow users to jump from one application form to another with the possibility of performing some processing once the user arrives at the new application form. (This is similar in concept to a hot key.) Note: Zooms are commonly used with Oracles character-based version. They are not commonly used (might not be supported) in their GUI version. Simple: Medium: Complex: Very Complex: 16 hours 32 hours 56 hours 80+ hours
Note: It is not certain whether these estimates only include just the development of these zooms or whether these estimates include development and unit testing. Simple: A simple zoom is one that only has one zoom event and few zoom steps and has little or no effect on the zoom-to location. Medium: A medium zoom is one that may have only one zoom event but several soom steps or have some effect on the zoom-to location. Complex: A complex zoom is one that has several zoom events each with several zoom steps that perform some function in the zoom-to location. (For example, copy data from source to destination, execute an automatic query at the destination, or update data either the source or destination location.) Very Complex: A very complex zoom is one where significant actions take place at both the source and destination locations using combinations of queries and triggers in multiple steps in each event. Following are some guidelines for developing Oracle Alerts.
29
2/26/2013
Note: It is not certain whether these estimates only include just the development of these alerts or whether these estimates include development and unit testing. Simple: A simple alert is one that incorporates simple SQL code to respond to well defined events or to perform very routine actions such as cleaning obsolete data out of a table. report is one that contains only one query and requires little formatting. Medium: A medium alert is one that incorporates more detailed actions in response to events and contain more complex SQL. Complex: A complex alert is one that might require several elegantly formatted detailed and summary actions in response to an event. Very Complex: A very complex alert is one that requires interaction with the operating system in conjunction with detailed actions. Estimate 40 hours of effort to develop one hour for hands-on (classroom-type) training with labs. Estimate 8 hours of effort to develop one page (8.5 x 11) of user documentation. Following are some generic custom development metrics. There numbers were based on a small sampling of projects and should be adjusted based on the knowledge of the specific project environment. The metrics assume that the development is client/ server using C++ or Visual Basic. They do not account for 4GL tools, prototyping, database activities, performance engineering, team leadership, or other support activities. The total hours cover design, code, unit test, and limited application/ integration testing. Simple Design Code Test Total: Note: These numbers seem to be on the low side when compared to other metrics provided above. Also it is uncertain at this time whether unit testing is covered in the coding or testing phase.
Medium 17 40 8 65
Complex 34 80 16 130
10 24 4 38
For completing a program, the following percentages can be used to break-down an estimate: Review Specification: Code Program: Compile Program: Code Review: Create Test Plan: Review Test Plan: Unit Test Program: Obtain Program Sign-off: 5% 15% 15% 5% 15% 5% 35% 5%
30
2/26/2013
Following is a proportional percentage by project phase: Requirements /BAA: BSD: Construction: Testing/ Pilot: 10% 20% 40% 30%
Notes: Construction includes unit testing. Testing and Pilot includes: String and Integration Testing: 40% of effort User Acceptance Testing: 40% of effort Performance Testing: 20% of effort As a reasonable sanity check for these phases, calculate the effort based on the anticipated staff count and duration. (Calculate each phase separately.) Cautions Following is a list of potential gotchas that could impact your ICD estimates. Review these and adjust your estimates, assumptions, or risk factors accordingly. Being forced to estimate the entire project up-front. Try to avoid estimating forward from the Requirements/BAA, especially if the Requirements/BAA has not been completed. 3-Tier environments add an additional layer of complexity. Adjust your estimates accordingly. The DBA staff being expected to build all stored procedures. Instead, allow the Application staff to build the procedures and have the DBA staff review them. It is essential to have a frozen architecture before you begin development. Failure to include time for all levels of testing; especially system and performance testing. Failure to distinguish between the various components of the application architecture: e.g. PowerBuilder, C, and stored procedures. Be sure to anticipate an lower level of utilization for client staff. Try to place these resources on non-critical paths. Remember to make allowances for computer operations. You will need them for critical items such as network support, backups, and DASD management. Allocate time for project manager, system architect (technical analyst), application architect (business analyst), test coordinator, and DBA roles. These individuals should be allocated for the entire ICD phase. Note: you can never bring in the test coordinator too soon. This individual will need time to understand the project-specific business requirements. System complexity can have a huge multiplier effect on your estimates. It is essential for the development staff to understand what done means before program development begins. One definition of done: A developer is done with a module when all coding has been completed, the code has been desk checked, the unit test plan has been completed and executed, all software documentation has been completed, and peer (or management) reviews of the code, test plan and results, and software documentation have been completed. Include time to account for miscellaneous development problem solving. These are generally unanticipated problems. Consider conducting regular meetings with key staff to look forward for unplanned tasks and potential workarounds. We occasionally forget to account for fixed support staff (architects, project managers, team leaders) when we adjust end dates due to schedule slips.
31
2/26/2013
32
2/26/2013
33
2/26/2013
34
2/26/2013
It is critical to have a System Architect during the design phases and then guide the development team to make sure the entire application works together. This person should review all developed software for consistency, adherence to standards, and usability. The System Architect should be on the project until the system is deployed.
35
2/26/2013
Communication Plans: The following formula can be used to estimate the effort to design and deliver communication events. The complexity of the engagement, the types of communication vehicles, the general readiness for change, and the length of the engagement are all factors that can influence this estimate. (# of stakeholder groups * # of project phases * # of hours per event * # of stages of acceptance) Notes: Estimating the number of stakeholder groups is discussed later in this section. Two guidelines have been given for estimating the hours per event. These guidelines include planning, designing, developing, approving, and deploying the communication event.
1. 2.
Two days to plan, design, approve, and execute an event. (This does not apply to a very sophisticated event such as a video component.)
An average of 4 to 20 hours per change enabling communication event. The number of stages of acceptance is 5. Another formula for estimating the amount of time required for change enabling communication follows. This formula guideline includes the time required ( in days) to plan, design, draft, and deploy the communication. (Effort = F * S * P * J) where: F = Complexity factor as calculated below S = Number of stakeholder groups P = Number of project phases (example, ETP and Requirements/BAA equals two phases) J = Judgment factor (use 5 for low-end, 10 for average, and 15 for high-end complexity)
36
2/26/2013
Example 1: Assume the change is minor, with some resistance anticipated, for a tactical change, and 7 stakeholder groups are involved -- the complexity factor (F) would be 1.0 x 1.2 x 1.2 x 1.0 = 1.44. Using this factor, we could estimate the effort during a Requirements/BAA to equal about 100 days. (Effort = F x S x P x J -- or -- 1.44 x 7 x 1 x 10 = 100) Example 2. Assume the change is major, with much resistance anticipated, for a strategic change, and 12 stakeholder groups have been identified -- the complexity factor (F) would be 1.4 x 1.4 x 1.4 x 1.2 = 3.95. Using this factor, we could estimate the effort during a Requirements/BAA to equal about 475 days. (Effort = F x S x P x J -- or -- 3.95 x 12 x 1 x 10 = 475) Stakeholder Groups: The following guidelines have been defined for estimating the number of stakeholder groups.
Minimum number of stakeholder groups for a small engagement is 4 (executive sponsors, project management, project team, and impacted business unit.) Minimum number of stakeholder groups for an enterprise-wide engagement is 6 (executive sponsors, project management, project team, extended project team, subject matter experts, and organization as a whole.) To calculate the lower boundary of the number of stakeholder groups: divide the number of fulltime project team members (FTEs including client staff) by four and add two. ((project team FTEs / 4) + 2) To calculate the upper boundary of the number of stakeholder groups: divide the number of fulltime project team members by two and add four. ((project team FTEs / 2) + 4) To estimate the number of stakeholder groups bases on the company size and percent of employees impacted by the change use the following tables to multiply the size (CS) factor by the percent of organizational change (PO) factor: Company Size CS factor 100 2 500 3 1,000 4 Up to 10% 1 5,000 5 10,000 6 50,000 7 25 to 80% 3 100,000 8 50 to 100% 4 500,000 9
10 to 30% 2
For example: Your client has approximately 5,000 total employees. The project is expected to only impact the corporate office, which accounts for 20% of the company. The estimated number of stakeholder groups is 10. (CS (5) * PO (2) = 10)
37
2/26/2013
Technical Infrastructure
No specific estimating guidelines have been identified at this time.
38
2/26/2013
39
2/26/2013
Appendices
Estimating Templates
Please refer to the additional file attachments for these spreadsheets. If you did not receive these file attachments or if you have any questions on how to use these spreadsheets, please contact any of the Estimating and Metrics team members.
Modifying the IT Services and Client spreadsheet to represent billable and non-billable effort. Modifying either spreadsheet to specify hours and costs by project phase, timebox, release, or development build.
To use these spreadsheets: 1. Enter the duration to hour conversion factor. This cell is used to calculate hours based on the duration that you have entered. The duration used in the template is weeks, so the duration to hour conversion factor has been set to 40 hours. 2. For each unique project role, enter a role description, the number of resources (count), the length of duration, and the hourly billing rate for this role. Add or delete roles as needed.
40
2/26/2013
3.
To use this estimating template: 1. Complete the PBD Details worksheet: a) Enter the estimating details on the PBD Details worksheet. The template contains some general activities for each of the package-based development sub-phases. Modify these activities to meet your specific project requirements. Define the key deliverables, estimating drivers, and comments for each activity. The estimating drivers should include: The unit of measure; such as a workshop, business function, timebox, or package. The number of units. The estimated effort to complete each unit.
The average number of staff involved in completing the activity. b) For the team leadership activity, enter the number of staff being managed and the percentage of team lead responsibility. (Note: Another option would be to include the team lead activities in the management and development coordination worksheet.) c) The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the bottom of the worksheet. The summary contains both hours and a percentage of the total effort. These hour totals are automatically linked to the estimate total worksheet. 2. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. For each role, enter a description, number of staff, and duration. The template currently assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your specific requirements.
41
2/26/2013
3.
42
2/26/2013
4.
To use this estimating template: 1. Complete the PGM Matrix worksheet: a) Enter the widgets that need to be developed into the appropriate categories. For each entry you can specify the name of the widget, cross-reference information, the number of units, and its level of complexity on a scale of 1 to 10. The worksheet will retrieve the per unit estimate from the estimate matrices worksheet, compute a total hour and day estimate based on the number of units specified, and calculate totals. Category and overall totals are provided. b) The categories contained on this template can be modified to meet your specific project. Additional categories can also be created if needed. If you do modify or add additional categories, corresponding changes will also need to be made to the other worksheets. (Caution: The per unit estimate column in this worksheet is extremely sensitive with the row and column coordinates within the estimate matrices worksheet. Be careful that you have defined the correct row and column coordinates when modifying this column.) 2. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. For each role, enter a description, number of staff, and duration. The template currently assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your specific requirements. (Note: Be sure to include the team lead activities in this worksheet. They have not been accounted for in the prior worksheet.) b) The worksheet will compute the total management and development coordination hours and automatically link this total to the estimate total worksheet. Complete the Est Ttl worksheet: a) Define the hour conversion factor; cell P3. This conversion factor is currently defined as 8 hours to convert the hour estimate to man-days. If you prefer to have man-months or man-years, adjust this factor accordingly. b) Enter the proportional factors for the BSD, ADC, Integration, and Deployment phases. The percentages currently defined in the worksheet are for illustration purposes only. c) As a option, you can define the management and coordination effort as a proportional factor; similar to the Integration and Deployment project phases rather than using a staff and duration estimate. To do this, enter the appropriate proportional factor and adjust the cell formula for the phase hours accordingly.
3.
43
2/26/2013
To use this estimating template, use the steps outlined for the single application spreadsheet. Repeat the ICD Matrix steps for each application area. The template currently allows for 2 application areas. You can adjust the spreadsheet to add more application areas.
3.
44
2/26/2013
The average number of staff involved in completing the activity. b) For the team leadership activity, enter the number of staff being managed and the percentage of team lead responsibility. (Note: Another option would be to include the team lead activities in the management and development coordination worksheet.) c) The worksheet will calculate sub-totals for each sub-phase and provide an overall summary at the bottom of the worksheet. The summary contains both hours and a percentage of the total effort. These hour totals are automatically linked to the estimate total worksheet. 2. Complete the Mgmt worksheet: a) Complete the staffing and duration template for the management and development coordination effort. For each role, enter a description, number of staff, and duration. The template currently assumes that the duration is specified in 40 hour weeks. Adjust the hour computation to meet your specific requirements. b) The worksheet will compute the total management and development coordination hours and automatically link this total to the estimate total worksheet. Complete the Est Ttl worksheet: a) Define the hour conversion factor; cell P3. This conversion factor is currently defined as 8 hours to convert the hour estimate to man-days. If you prefer to have man-months or man-years, adjust this factor accordingly. b) Enter the proportional factors for Integration and Deployment. The percentages currently defined in the worksheet are for illustration purposes only. c) As a option, you can define the management and coordination effort as a proportional factor; similar to the Integration and Deployment project phases rather than using a staff and duration estimate. To do this, enter the appropriate proportional factor and adjust the cell formula for the phase hours accordingly. Multiple Application Spreadsheet: This spreadsheet contains the same three worksheets as the single application spreadsheet plus an additional summary worksheet. This additional worksheet, XAD Summary, provides an hour and percentage summary for each application. To use this estimating template, use the steps outlined for the single application spreadsheet. The only difference is in the XAD Details worksheet. This worksheet allows you to enter detail estimating information for each application area. The template currently allows for 3 application areas. You can adjust the Est Ttl, XAD Summary, and XAD Detail worksheets to add or subtract application areas.
3.
45
2/26/2013
46
2/26/2013