Proposal, Cost Estimate, Consulting by quu17210

VIEWS: 125 PAGES: 126

More Info
									     ITPM Today—3/2/2010
1.PERT REVIEW (last part of Ch
                 7)
  2. The Proposal—due Friday.
               10/10
3. Time and Cost Estimation (Ch.
          8, copy packet)
        (OUR WEAKEST LINK)
    PERT (Program Evaluation and
        Review Technique)
 Not supported by MS Project
 Gives you probabilities of completion of a
  project by a certain time
 Calculates a standard normal random
  variate and uses a probability table to find
  its probability
            PERT INPUTS
 A = most optimistic time
 M = most likely time
 B = most pessimistic time
            PERT formulas
 Task mean = (A + 4*M + B)/6
 Task Std. Dev. = (B-A)/6
 Project mean = sum of all the task means of
  tasks on the critical path
 Project std. Dev = sum of all the task
  standard deviations of tasks on the critical
  path
PERT Homework Assignment
            THE PROPOSAL
 You want it by When????
 Primarily a selling document
 I will grade it on the basis of:
    – How well you sold the product
    – How well you sold yourself
 Are cost and duration the two most
  important parameters in the Proposal?
 Use the format outlined in Chapter 11!
                   Proposal
    Address it to the customer, not me (your
     instructor)
    ADVANTAGES SECTION
    1. Describe advantages of your proposed
       solution
    2. Describe why you or your firm should be the
       one chosen to do this excellent work
Proposal Methodology in the real
            world
 Your proposal will be reviewed and
  approved in-house before it is allowed to go
  to the customer
 Sometimes a proposal manager conducts the
  review
 Budget gets checked
 Boilerplate must be there to protect the
  proposer/contractor
       PROPOSAL CONTENTS
A. COVER LETTER                             (SEPARATE PAGE)


B. TITLE PAGE                      (SEPARATE PAGE)


C. TABLE OF CONTENTS                                          (SEPARATE PAGE)


1. Scope            (SEPARATE PAGE—SCOPE OVERVIEW, FOLLOWED BY YOUR PROPOSED SOLUTION)


2. Advantages                   (OF YOUR PROPOSED SOLUTION AND WHY YOU SHOULD BE SELECTED
TO DO THE WORK)


3.    Financial          (USE SAME BREAK-EVEN CHART YOU USED IN YOUR PROJECT PLAN)


4.    Plan        (JUST AN OVERVIEW HERE)


5.    Deliverables                (AND THEIR DUE DATES)


6.    Acceptance                (DISCUSS YOUR ACCEPTANCE METHODOLOGY HERE)


7.    Alternatives
8.    Terms, Conditions and Assumptions
9.    Terminology
            Cover Letter
Follow the style exhibited in the copy
 packet, chapter 11
        Estimation: An ART
 That made McDonnell (of
  McDonnell/Douglas Aircraft) wealthy
 Accurate intelligence information is a help
    INPUTS             TOOLS                 OUTPUTS

1. Activity list   1. Expert
2. Constraints
                                         Activity
                                        1.
                   judgment
3. Assumptions                          duration
4. Resource        2. Historical data
requirements       3. Analogous         estimates
5. Resource        estimating
capabilities       4. Simulation
6. Historical                           2. Basis of estimates
                                        3. Activity list updates
information
     The Cost estimation Story—
          Steve McConnell
   You can’t tell exactly what its going to cost

    until you know exactly what   IT is.
   (Which is why we spent so much time
    talking about thorough product
    conceptualization and definition)
            A Rule of Thumb
 The time to design, document and code a
  module =
 equals the time to debug it (TEST IT)


   According to Gildersleeve
       Estimating Rules (Rakos)
   Never use inexperienced persons to estimate
   Get group estimates if possible
   Never force an estimate on a programmer
   Never take an average of different estimates
   Granularize down to FOUR or less weeks, roughly
   Always add for contingency
   Always quote a range when giving estimates
        Rakos’ Conclusions to
             Estimating
 Our weakest talent
 Estimating is iterative
 Estimating is still an art
         Review: Project Time
         Management Processes
   Project time management involves the processes
    required to ensure timely completion of a project.
    Processes include:
    – Activity definition
    – Activity sequencing
    – Activity duration estimating
    – Schedule development
    – Schedule control
   Which of these gets performed in the Planning
    and Budgeting Stage??
A Typical Task Duration Process
   Assign the task to a project player
   Ask the player how long it will take him or her to
    complete the task (This gives the player ownership
    in the planning)
   Player provides their best estimate
   The player understands that they will be required
    to complete the task within their estimate—their
    feet will be ―held to the fire‖
    Time Estimation: Goldratt
 Claims team players add safety to their
  estimates
 What is safety??
 Can determine how much by asking the
  question, ―How sure are you that you will
  finish your task in the time you allotted?‖
    Time Estimation--programmers
   Naïve programmers have a horrible
    reputation for underestimating task
    durations and costs
    Time Estimation—making time
       for creativity: SLACK
 Keep in mind that customers unintentionally
  put projects under extraordinary schedule
  pressure—more for less
 A consideration in schedule development is
  to take the tasks requiring creativity and
  place them on ____?!?
      Too little time syndrome

                         More stress




                                        More mistakes
More schedule pressure




                     missed deadlines
    Needed: A Rule-based Expert
    System for adjusting individual
            task durations
   IF ESTIMATER IS SEASONED AND IF THE
    WORK PACKAGE REQUIRES CREATIVITY
    ON THE PART OF THE ESTIMATOR, THEN
    LEAVE ESTIMATE AS IS.
   IF ESTIMATER IS NOT SEASONED AND
    ESTIMATE APPEARS TO BE OPTIMISTIC,
    THEN INCREASE ESTIMATE BY 30%.
        ANOTHER AI RULE
   IF ESTIMATOR IS SEASONED AND
    ESTIMATOR ASSERTS 90% OR ABOVE
    CONFIDENCE HE WILL COMPLETE
    WORK WITHIN HIS ESTIMATE AND IF
    WORK PACKAGE DOES NOT REQUIRE
    SIGNIFICANT CREATIVITY, REDUCE
    ESTIMATE BY 50%
             Time Estimation
   What are the three approaches to time
    estimation??
    – Expert judgment
    – History database
    – Computer model or formula
             Lefkon’s Methodology
1.   Divide the software project into as many individual
steps/tasks/modules as possible.
2. Predict the level of effort required to complete each task and
multiply that prediction by 2.
3. Add up the numbers and multiply by 2.0 again to account for
testing and debugging.
4. Take the total and multiply by 1.25 to account for meetings,
administration, and paperwork.
5. Multiply this level of effort by your company’s ―magic number‖
for labor costs.
        Lefkon’s Methodology
6. Present this to management as a range. Take the
   cost as predicted above and present the range as –
   10 percent and +25 percent.
7. Stand your ground and remind management that you
   did not arbitrarily come up with these numbers and
   they cannot be adjusted arbitrarily. You may have to
   suggest reducing scope and cost if management
   does not agree with your estimate.
8. Revise your project budget as you undertake and
   complete the project.
    Project Cost Management Processes
   Resource planning: determining what resources and
    quantities of them should be used
   Cost estimating: developing an estimate of
    the costs and resources needed to complete
    a project
   Cost budgeting: allocating the overall cost estimate
    to individual work items to establish a baseline for
    measuring performance
   Cost control: controlling changes to the project
    budget
            Cost Estimating
We need to speak the language and
 understand the terminology:
  ROI, IRR, NPV, Sunk costs
  Tangible and intangible costs
  Direct and indirect costs
  Learning curve theory
  Reserves ($ included in a cost estimate to
   mitigate cost risk; also called contingency
   reserves)
            Cost Estimating
 An important output of project cost
  management is a cost estimate
 There are several types of cost estimates
  and tools and techniques to help create them
 It is also important to develop a cost
  management plan that describes how cost
  variances will be managed on the project
     Proposal Pricing Strategies--
               Kerzner
   Type I Acquisition: One of a kind project
    with little or no follow-on opportunity
       » win the project, perform well and make a profit
   Type II Acquisition: New Program with
    potential for large follow-on business or
    representing a desired surge into a new
    market
       » win the project, perform well and gain a foothold in
         a new market segment, usually at a loss
             Table 6-2. Types of Cost
                    Estimates
  Type of Estimate        When Done                 Why Done          How Accurate
Rough Order of       Very early in the         Provides rough         –25%, +75%
Magnitude (ROM)      project life cycle,       ballpark of cost for
WAG                  often 3–5 years           selection decisions
SWAG                 before project
                     completion
Budgetary            Early, 1–2 years out      Puts dollars in the    –10%, +25%
                                               budget plans
Definitive           Later in the project, <   Provides details for   –5%, +10%
                     1 year out                purchases, estimate
                                               actual costs
Estimation in General—COST or
             TIME
 History data base
 Expert judgement
 a model like COCOMO
Cost Estimation Tools and Techniques
   4 basic tools and techniques for cost estimates
    (Schwalbe—Ch 6):
    – Analogous or top-down: use the actual cost of a previous,
      similar project as the basis for the new estimate
    – Bottom-up: estimate individual work items and sum them
      to get a total estimate
    – Parametric: use project characteristics in a mathematical
      model to estimate costs
    – Computerized tools: use spreadsheets, project
      management software, or other software to help estimate
      costs
    Constructive Cost Model
         (COCOMO)
 Barry Boehm helped develop the COCOMO
  models for estimating software development
  costs
 Parameters include source lines of code or
  function points
 COCOMO II is a computerized model
  available on the web
 Boehm suggests that only parametric models
  do not suffer from the limits of human
  decision-making
    Typical Problems with IT Cost
              Estimates
   Developing an estimate for a large software project is a
    complex task requiring a significant amount of effort.
    Remember that estimates are done at various stages of the
    project
   Many people doing estimates have little experience doing
    them. Try to provide training and mentoring.
   IT People have a bias toward underestimation. Review
    estimates and ask important questions to make sure
    estimates are not biased
   Management wants a number for a bid, not a real estimate.
    Project managers must negotiate with project sponsors to
    create realistic cost estimates
    Table 6-3. Business Systems Replacement
Category
         Project Cost Estimate Overview
                          Description
Objective                         Install a suite of packaged financial applications
                                  software which will enable more timely
                                  information for management decision-making,
                                  easier access to data by the ultimate end user, and
                                  allow for cost savings through productivity
                                  improvements throughout the company.
Scope                             The core financial systems will be replaced by
                                  Oracle financial applications. These systems
                                  include:
                                      General Ledger
                                      Fixed Assets
                                      Ops Report [AU: spell out Ops]
                                      Accounts Payable
                                      Accounts Receivable
                                      Project Accounting
                                      Project Management
Assumptions                       Oracle's software provides

                                     Minimal customization
                                     No change in procurement systems during
                                      accounts payable implementation
Cost/Benefit Analysis             BSR was broken down into a three-year cash
& Internal Rate of Return (IRR)   outlay without depreciation. Costs are
                                  represented in thousands. Capital and expenses
                                  are combined in this example.
Table 6-4. Business Systems Replacement
       Project Cash Flow Analysis
                           FY95       FY96       FY97         3 Year    Future Annual
                                                               Total    Costs/Savings
                           ($000)     ($000)     ($000)       ($000)        ($000)
 Costs
 Oracle/PM Software             992        500            0      1492               0
 (List Price)
     60% Discount             (595)                             (595)
     Oracle Credits           (397)          0                  (397)
 Net Cash for Software            0        500                    500
 Software Maintenance             0         90        250         340             250
 Hardware & Maintenance           0        270        270         540             270
 Consulting &Training           205        320          0         525               0
 Tax & Acquisition                0        150         80         230              50
 Total Purchased Costs          205       1330        600        2135             570
 Information Services &         500       1850       1200        3550               0
 Technology (IS&T)
 Finance/Other Staff            200        990        580        1770
 Total Costs                    905       4170       2380        7455             570

 Savings
 Mainframe                               (101)      (483)       (584)            (597)
 Finance/Asset/PM                        (160)     (1160)      (1320)           (2320)
 IS&T Support/Data Entry                  (88)      (384)       (472)            (800)
 Interest                                    0       (25)        (25)            (103)
 Total Savings                           (349)     (2052)      (2401)           (3820)

 Net Cost (Savings)             905       3821        328        5054           (3250)

 8 Year Internal               35%
 Rate of Return
             Cost Budgeting
 Cost budget involves allocating the project
  cost estimate to individual work items and
  providing a cost baseline
 For example, in the Business Systems
  Replacement project, there was a total
  purchased costs estimate for FY97 of
  $600,000 and another $1.2 million for
  Information Services and Technology
 These amounts were allocated to appropriate
  budgets as shown in Table 6-5
 Table 6-5. Business Systems Replacement Project
   Budget Estimates for FY97 and Explanations
  Budget Category      Estimated Costs                    Explanation
Headcount (FTE)                     13   Included are 9 programmer/analysts, 2
                                         database analysts, 2 infrastructure
                                         technicians.
Compensation                $1,008,500   Calculated by employee change notices
                                         (ECNs) and assumed a 4% pay increase in
                                         June. Overload support was planned at
                                         $10,000.
Consultant/Purchased          $424,500   Expected consulting needs in support of the
Services                                 Project Accounting and Cascade
                                         implementation efforts; maintenance
                                         expenses associated with the Hewlett-
                                         Packard (HP) computing platforms;
                                         maintenance expenses associated with the
                                         software purchased in support of the BSR
                                         project.
Travel                         $25,000   Incidental travel expenses incurred in
                                         support of the BSR project, most associated
                                         with attendance of user conferences and
                                         off-site training.
Depreciation                   $91,000   Included is the per head share of
                                         workstation depreciation, the Cascade HP
                                         platform depreciation, and the depreciation
                                         expense associated with capitalized
                                         software purchases.
Rents/Leases                   $98,000   Expenses associated with the Mach1
                                         computing platforms.
Other Supplies                $153,000   Incidental expenses associated with things
and Expenses                             such as training, reward and recognition,
                                         long distance phone charges, miscellaneous
                                         office supplies.
Total Costs                 $1,800,000
          Designing the Baseline
   One of the most crucial inputs to the pricing
    decision
   Baseline design should be started early so its cost
    estimates can be included in the proposal
   Effective pricing should begin a long time before
    proposal development
    – Gives management an opportunity to terminate a bid
      initiative before too many resources get committed to
      proposal development, presentations, negotiations, etc..
            Pricing Process
 This activity schedules the development of
  the work breakdown structure and provides
  management with two of the three
  operational tools necessary for the control
  of a system or project
 The third tool is the WBS
The WBS as price estimating tool
 Provides the basis for effective and open
  communication between functional
  management and program/project
  management
 After pricing is complete the WBS forms
  the basis of a communications tool by
  documenting the performance agreed on in
  the pricing effort.
            Organizational Input
               Requirements
   After the WBS and activity schedules are
    established, an organizational meeting is called.
    – The WBS is described in depth
    – Responsibilities are clarified
    – Costing information is solicited and collected from the
      responsible parties
   A short time fuse is usually involved in
    estimating/pricing which makes it all the more
    risky
    – RFP’s sometimes require a response within 30 days of
      their submittal
              Labor Distributions
   Functional units supply their input in the form of
    man-hours
        » See Figure 14-2
   Man-hours submitted are often over-estimated
   Man-hours are converted to dollars by multiplying
    by the labor rates
   Rates are only averages
   Base rates are then escalated as a % factor, based
    on past experience
    Labor Distributions--Conflict
            Resolution
 The reduction of man-hours is often the
  source of heated discussions between
  project and functional management
 Most common solution rests with the
  project or program manager
 This becomes the usual turf-fight
 How would you resolve all such
  conflicts???
         A Proposal Manager
 Integrates the activities of the program and
  functional managers
 Insures that a robust proposal gets
  submitted to the REQUESTER on time
               Overhead Rates
   Program/project costs involve both direct labor
    and indirect (OVERHEAD) costs
   Each team member should understand overhead
    rates
   If overhead rates are more than 50% of direct
    regular time and not chargeable to overtime, then
    overtime at 150% regular time may be cheaper
   Overhead rates in manufacturing can be 300-450%
     Elements of Overhead Rates
          (Indirect Costs)
   Building maintenance        Group insurance
   Building rent               Holidays
   Cafeteria                   Moving/storage exp.
   Clerical                    Personnel recruitment
   Consulting                  Retirement plans
   Corporate Salaries          Sick leave
   Depreciation of equip.      Telephone/Utilities
   Executive Salaries          Vacation
Why are Overhead Rates of Interest to
      Project Management???
   These rates must be included in any project
    cost calculation!!!
   The contractor is going to pay both your
    direct and your indirect overhead costs if
    yours is the winning bid
   Where do the costs associated with bidding
    and proposing go? Does anybody pay for
    them or are they just a SUNK cost???
    Let’s REVIEW: What are the
      Major Cost Components?
 Salary structure
 Overhead structure
 Labor hours required
 Cost of materials and support
        Cost of Materials??
 Required Software
 Diet coke, pizza
      Materials Support Costs
 Are submitted by month for each month of
  the project
 An escalation factor for material costs must
  be applied
    Pricing out the Work—STEPS
        (from Kerzner, p. 738)
 Provide a complete definition of the work
  requirements
 Establish a logic network with checkpoints
 Develop the work breakdown structure
 Price out the WBS
    Pricing out the Work--STEPS,
                Cont’d
 Review WBS costs with each functional
  manager
 Decide on the basic course of action
 Establish reasonable costs for each WBS
  element
 Review the base case costs with upper-level
  management
    Pricing out the Work--STEPS,
                Cont’d
 Negotiate with functional managers for
  qualified personnel
 Develop the linear responsibility chart
 Develop the final detailed and PERT/CPM
  schedules
 Establish pricing cost summary reports
 Document the result in a project plan
Smoothing out Department Man-
            hours
   Ramp-up at project initiation and Ramp-down at
    project completion cause step functions in
    manpower requirements, as shown in Figure 14-8
   Functional managers attempt to SMOOTH this out
   QUESTION?? Does the department have
    sufficient resources to fulfill the requirements?
Smoothing out Department Man-
            hours
   ANOTHER QUESTION?? Can the
    departments ramp-up fast enough?
    The Pricing Review Procedure
 Based on Kerzner’s work
 Remember only 30 days to get the proposal
  out and this is one of 13 steps
 Many contractors require the actual team
  members to be identified in the proposal
 What solution comes to mind?
            Systems Pricing
 The project pricing model (also called the
  strategic planning model) acts as a
  management information system
 Also provides management with an
  invaluable tool for performing perturbation
  analysis on the base case costs
         Developing the
     Supporting/Backup Costs
 Some proposals require backup support
 When required backup support must be
  included in the pricing
 An issue is the type of contract
          Types of contracts
 Fixed-price (developer assumes all of the
  risk)
 Cost-plus (contractor pays for every hour
  invested and thus assumes all the risk)
 An infinite array in between these
    The Low-Bidder Dilemma
 The price of your contract will definitely
  affect the viability of your proposal
 A low price on cost-plus type proposals is
  suspect
 A low price on fixed-price contracts may be
  perceived as impossible and undoable, or if
  accepted will lead to a disaster
    The Price on the Proposal is
        always relative to:
 the competitive prices
 the customer budget
 the bidder’s cost estimate
 IN ANY CASE, LOW PRICING
  WITHOUT MARKET INFORMATION IS
  MEANINGLESS
     If its a new market for the
              Developer:
 Cost sharing may be an effective strategy
 Bidding below your actual costs is
  commonplace
 Contractor’s objectives might include
  system life cycle cost or unit production
  cost
       The Bottom Line on Price
   THE LOWEST BIDDER IS NOT
    NECESSARILY THE AUTOMATIC WINNER
    – Makes project a risky image regarding cost,
      performance or schedule
   The ability to perform under contract is a definite
    consideration
   A compliant, technically and managerially sound
    proposal based on past experience, with realistic,
    well-documented cost figures, is often chosen over
    the lowest bidder
                     Special Problems
• Pricing must include an understanding of cost control--
  how costs are billed back to the project
• There are three situations:
   – Work is priced out at the department average, and all
     work performed is charged to the project at the
     department average, regardless of who performed the
     work
   – Work is priced out at the dept.. average, but all work
     performed is billed back to the project at the actual
     salary of the employees who performed the work
   – Work is priced out at the actual salary of those
     employees who will perform the work, and the cost is
     billed back the same way.


      » This is the ideal situation
This is as far as we will go with
   these slides—ignore the
           remainder
            Estimating Pitfalls
• The “buy-in” decision is the most serious pitfall
  because it means that the project will be under-
  funded
• If the customer initially defines the requirements
  and you (the developer) further refine them and
  the customer doesn’t understand what you’ve
  done, whose fault is it?
  Estimating High-Risk Projects
• Validity of historical estimates determine the
  difference between high-risk and low-risk
  projects
• Estimating high-risk projects is commonly done
  by means of the rolling wave or moving window
  approach
   – For a 12-month project the first six months are
     estimated to level 5, while the last six months are
     estimated to level two only.
   – As the project proceeds more and more of the last six
     months is estimated to level 5
   – See Figure 14-13, Kerzner
                Project Risks
   RISKS--Factors that increase the
    probability that the project’s goals of time,
    cost and performance will not be met
• See Figures 14-14, 14-15 and Table 14-13
  (Especially useful)
      Common Risks include:
 Poorly defined requirements
 Lack of qualified resources
 Lack of management support
 Poor estimating
 Inexperienced project manager
        Tools to Aid in Risk
           Identification
 Decision Support Systems
 Expected value measures
 Trend analysis/projection
 Independent reviews and audits
Six steps to risk management are:
 Identification of the risk
 Quantification of the risk
 Prioritizing the risk
 Developing a strategy for managing the risk
    – A contingency plan
 Project sponsor/executive review
 Taking action
The Disaster of Applying the 10
% Solution to Project Estimates
   10% is taken from every on-going project to create
    a budget out of thin air
   The result is havoc on top of chaos
   Most high-level executive committees do not
    realize the impact of adopting the 10% solution
   A REDUCTION IN BUDGET MUST BE
    ACCOMPANIED BY A TRADEOFF IN TIME
    OR PERFORMANCE
        The Disaster of the 10%
           Solution, Cont’d
 90% of the budget generates 10% of the
  desired service or performance levels and
  the remaining 10% will generate the last
  90% of the desired service or performance
 If there is FAT, i.e., padding, it may,
  however, be possible to sustain a cut in the
  project budget without major consequence
    – Most projects do not have FAT
        Cost vs. Performance
 I much prefer the word performance to
  quality here
 A 10% reduction in cost can be expected to
  produce much greater than a 10% reduction
  in performance
     More on the 10% Solution
 10% reduction solutions should be
  undertaken only after a careful impact study
  has been completed
 A far better choice is for the executive
  committee to cancel or de-scope some
  projects in order to release funds
14.19 Life-Cycle Costing (LCC)
 These are the total costs to the organization
  for the ownership and acquisition of a
  product over its full life
 Especially appropriate for in-house software
  development projects, but is used in some
  (outhouse) contracted projects as well
    Life-cycle cost breakdown
 R & D Costs (Definition, Analysis)
 Production cost (Design)
 Construction cost (Programming and
  testing)
 Operation and maintenance cost
 Product retirement cost
     Life-cycle costing process
 Define the problem
 Define the requirements of the cost model
  being used
 Collect historical data-cost relationships
 Develop estimates and test results
    Successful applications of LCC
                 will:
 Provide downstream resource impact
  visibility
 Provide life-cycle cost management
 Influence R&D decision making
 Support downstream strategic budgeting
          Estimating Methods for LCC
   Method choice is based on the problem context,
    operational considerations, etc.
   Informal estimating methods
    –   Judgment based on experience
    –   Analogy
    –   SWAG method, ROM method
    –   Rule-of-thumb method
   Formal estimating methods
    – Detailed (from industrial engineering standards)
    – Parametric
             Figure 14-18
 For every $12 DOD puts into R&D, $28 are
  needed downstream for production and $60
  for operation and support
 After Conceptual definition and
  demonstration/validation, 85% of the
  lifecycle decisions are made and cost
  reduction opportunities are down to 22%
         14.20 Logistics Support
   A frequent occurrence in software development
    where the developer is paid to provide after-
    market support in the form of operation and
    maintenance on the product (deliverable)
   Recall that after the design phase 85% of the
    deliverable’s life-cycle cost has been committed
    and the majority of the total life-cycle cost is still
    ahead >> 60%
Performance metrics for Products
   requiring Logistics Support
 Suppportability--the ability to maintain or
  acquire the necessary human resources to
  support the system
 Readiness--measure of how good we are at
  keeping the product performing as planned
  and how quickly we can make repairs
  during a shutdown
Ten elements of logistics support
   Maintenance planning    Training and
   Manpower and             training support
    personnel               Computer resources
                             support
   Supply support
                            Facilities
   Support equipment       Packaging,
   Technical data           handling, storage
   See page 765             and transportation
                            Design interface
                Estimating --
   An iterative process
    – Definition, Analysis, Design
 After Definition, 50-100% off
 After Analysis, 25-50% off
 After Medium level design--within 10%
 A good WBS is absolutely essential to do
  estimating
      Estimating Techniques
 Professional Judgment
 Developer estimate
 History (database)
 Formulas
    Use of Professional Judgment
 Based on WBS, an expert judgment
  estimate is made for each work package
 Amazingly accurate when experts are
  available
 Often, however experts aren’t available
           Developer Estimate
   The programmer assigned to the work
    package will make every effort to complete
    the task in the time he estimated it would
    take
      Use of History Database
 For this to work, your firm must keep a
  history database
 The database should record how long each
  task took and who did the task
 Break new projects up into tasks that have a
  history database
 8 to 1 productivity ratio between best to
  worst professional
               Questions, Cont’d
   How much of the total time does Brooks devote to
    Definition, Analysis and Design?
             1/3
   How much time to coding?
             1/6 to Coding
   How much time to testing?
             1/4 to component test and early system test
             1/4 to total system test
   So how much time are you going to devote to
    testing in your projects?????
              Use of Formulas

   COCOMO--project cost, effort, schedule,
    staffing for each of the phases:
    –   Preliminary design
    –   Detailed design
    –   Code and unit test
    –   System test
   COCOMO was developed by Barry Boehm
    in 1981--COnstructive COst MOdel
         Inputs to COCOMO
 Monthly cost of staff involved
 Factors indicating the general level of
  complexity of the software
 Programming practices and tools used
 Experience of staff
 Lines of LOSC--rendering COCOMO
  unusable
           Function Points
 A user input
 User display
 Peripheral I/O
 Restructuring data
 Condition checking
 Calculation
 Branching
     Function point approach--
      BEFORE YOU LEAP
 Vendor is Gordon Group
 It must know how many LOSC are required
  for each function point.
 It calculates LOSC based on function points
  it knows about and feeds this into the
  COCOMO algorithm
    Estimacs from CA (Computer
            Associates)
 Can take into account modern code
  generation tools
 Determines effort, but also
    –   Hardware required
    –   financial break-even analysis
    –   risk analysis
    –   maintenance costs
   Expensive > $20K
     Estimating Programming:
          Function Points
 D = C * ( G + J)
 D is the task duration in person-days
 C is the complexity of the task
 G is the assigned persons’ general
  experience
 J is the assigned professional’s job
  knowledge factor
                         Complexity
 Must break task down into its smallest
  possible repeatable functions
 Then add up the complexity of each
  function
 User input, user display, peripheral I/O,
  restructuring data, condition checking,
  calculation, etc.
   Repeatable functions are called function points.
   Function points are graded as SIMPLE, COMPLEX and VERY
    COMPLEX
             Productivity
 Your average programmer gets a
  productivity factor of 1 for G
 Slower programmers get factors > 1
 Faster programmers get factors < 1
    Formula method conclusions
 Will work if you develop accurate factors
 Can be used for any task from building a
  house to developing software
 Depends on how well you granularize
    Estimating The Analysis Phase
 Interviews
 Analyze Existing Documents and Systems
 Prepare Functional Specification
 Presentation
              RATIOS

 PHASE                 PERCENTAGE
 Definition phase -- 10%
 Analysis phase -- 20%
 Design phase    -- 10%
 Programming     -- 20%
 System test     -- 17%
 Acceptance       -- 7%
 Operation        -- 16%
       This breaks down to:
 PLAN -- 40%
 BUILD -- 20%
 TEST -- 40%
        Another Rule of Thumb
 The time to design, document and code a
  module =
 equals the time to debug it


   According to Gildersleeve
     Can you use RATIOS for
          Forecasting?
 Suppose you found that it took 20 days to
  do definition.
 How long, based on ratios will it take to do
  the project?
              Estimating Rules
   Never use inexperienced persons to estimate
   Get group estimates if possible
   Never force an estimate on a programmer
   Never take an average of different estimates
   Granularize down to one week or less
   Always add for contingency
   Always quote a range when giving estimates
     Conclusions to Estimating
 Our weakest talent
 Estimating is iterative
 Estimating is still an art
                Scheduling --
   Also assists with estimating, especially
    when PM software is used
       PM software supports
 WBS
 Gantt
 PERT
 Calendar(s)
 Resources and their assignments
                      PERT
   Use activity on node approach
    – doesn’t require dummy activities
 Understand what float is--it is slack
 Critical path is the longest path
 shows precedent activities, relationships
 doesn’t show what will be done when, by
  whom
         Resource allocation
 Assign tasks to individuals whose skill level
  suits the task
 Assign similar tasks to the same person
 Assign time-critical tasks to your most
  reliable people
 Assign tasks that communicate to the same
  individual to minimize people’s interaction
 Don’t assign too many different tasks to any
  one individual
Reducing task duration by adding
           manpower
 Add 20% direct time for each additional
  member on a professional team
 If it takes 10 person days for one person, it
  will take 12 person days for two people,
  14.4 person days for three people, etc.
 Cost effects of adding resources
 More resources, gets the project done
  sooner, USUALLY
 But it also costs more
 The PM must come up with the best
  balance, depending on the priorities set by
  management or the user
      Shortening the duration of
               projects
 Fast tracking
 Crashing
    – Adding resources to the critical path
    – Allowing your current CP teams members to
      work overtime
           Crashing projects
 Crash tasks on the critical path only, only as
  long as no other path becomes critical
 If other paths become critical, the analyst
  must crash those as well
              Gantt Chart
 a time bar chart
 Invented by Henry Gantt in 1910
 Determine the units of time
 Mark all known calendar events at bottom
 Schedule each activity from PERT
      Use three sets of Gantt’s
 one for yourself alone, with all float and
  contingency visible
 second for the individuals involved--their
  resource Gantt, contingencies hidden
 third for distribution to upper management--
  contingencies hidden
 Include a 10% contingency into all
  estimates
    Conclusions to Scheduling
 Use PM software--worth every penny
 Do at least one PERT and one GANTT
  manually, just to get a feel for the process
                   Recitation
   What is the probability of completing a project by
    its estimated completion time??
   What is the formula for calculating the completion
    time for a PERT network?
   What is the formula for calculating the standard
    deviation of the completion time for a PERT
    network?
   Name some processes that are part of project
    integration management

								
To top