3.2 Timing and Risks of the Project, Criteria for Project Acceptance, Justification of the Project Utility

Lecture



Timing

F. Brooks [3] wrote: “It takes nine months to give birth to a child, regardless of how many women are involved in this task. Many programming tasks are of this type, since debugging is inherently consistent. ”

In the same place, Brooks gives an exceptionally useful, but for some reason rarely used, empirical formula for estimating the duration of a project according to its labor intensity. The formula was derived by Barry Boehm based on an analysis of the results of 63 software development projects, mainly in the aerospace field. According to this formula, for the project, the total labor intensity of which is N h. * M. (man-months), it is argued that:

  • There is an optimal, in terms of costs, schedule execution time for the first delivery: T = 2.5 (N h. * M.) 1/3. That is, the optimal time in months is proportional to the cubic root of the estimated amount of work in man-months. The result is a curve that gives the optimal size of the project team (Figure 15).
  • The cost curve slowly grows if the planned schedule is longer than the optimal one. The work takes all the time allotted to it.
  • The cost curve rises sharply if the planned schedule is shorter than the optimal one. Virtually no project can be completed faster than 3/4 of the calculated optimal schedule, regardless of the number of employees in it! (Figure 16)

This remarkable result gives the software project manager solid support when top management demands the adoption of an impossible schedule.

  3.2 Timing and Risks of the Project, Criteria for Project Acceptance, Justification of the Project Utility
Figure 15. B. Boehm's Law

For any serious software project, it is not enough to determine only the date of its completion. It is also necessary to determine its stages, the control points where the project will be re-evaluated on the basis of actually achieved indicators.

The control point is an important moment or event in the project schedule, marking the achievement of a given result and / or the beginning / completion of a certain amount of work. Each control point is characterized by a date and objective criteria for achieving it.

As we said earlier, a modern software development project should be implemented using an incremental process. In this case, the control points must correspond to the release of each intermediate version of the software in which a certain part of the final functionality of the software product will be implemented and tested. Depending on the complexity and scale of the project, the duration of one iteration can be from 2 to 8 weeks.

  3.2 Timing and Risks of the Project, Criteria for Project Acceptance, Justification of the Project Utility
Figure 16. Implications of B. Boehm’s Law

The relevant section of the concept of our example project will be as follows.

  1. Project Dates

    9.1. 03.03 start
    9.2. 28.11 completion
    9.3. Checkpoints:
    9.3.1. 15.04 TK approved
    9.3.2. 30.04 1st iteration is completed. The documentation ordering subsystem has been transferred to test operation (on the developer’s servers).
    9.3.3. 15.05 Installation of equipment at the customer is completed.
    9.3.4. 30.05 The basic software is installed at the customer.
    9.3.5. 15.06 The 2nd iteration is complete. The order processing subsystem has been transferred to test operation on the Customer’s equipment.
    9.3.6. 02.09 3rd iteration is completed. The act of transferring the system to trial operation has been approved
    9.3.7. 28.11 The system is transferred to industrial operation.

Risks

Risk - an uncertain event or condition, the occurrence of which adversely or positively affects the objectives of the project [1].

As a rule, in the event of a negative risk, the cost of the project almost always increases and there is a delay in the implementation of the activities provided for in the project schedule. Project risk management will be a separate lecture.

At the initiation stage, when the necessary data are not available for detailed analysis, it is often necessary to limit oneself to a qualitative assessment of the overall level of risks: low, medium, high.

In the case of our example project, the “risks” section will look like this.

  1. Project risks

    10.1. The tasks of the system are not fully understood. Understanding the scope and scope of the project is not enough. Systems are created on a new technological platform, doubts about the market stability of the platform. The total risk level should be rated above average.

Acceptance criteria

Acceptance criteria should determine the numerical values ​​of the system characteristics, which should be demonstrated by the results of acceptance tests or trial operation and clearly indicate the achievement of project objectives.

In this example, the section "Acceptance criteria" will be as follows:

  1. Acceptance criteria According to the results of trial operation, the system should demonstrate the following indicators:

    11.1. The average expenses of the “123” Department employees for the procedural processing of one order do not exceed 4 people * hours.
    11.2. The term of the scheduled processing of the 1st order is not more than 2 weeks.
    11.3. Time to search and provide information on the availability of additional documentation no more than 1 min.
    11.4. The time of providing information about orders made and the history of their processing is not more than 1 min.
    11.5. The system stores all information about orders made and their processing history.
    11.6. System availability rate of 98%.

Project Justification

This section of the concept should contain a brief feasibility study of the project:

  • For whom are the results of the project.
  • Description of the current situation "As Is". What are the potential customer problems?
  • How the results of the project solve these problems (“To Be”).
  • How important is the solution of these problems for the client (assessment of the economic effect).
  • What advantages in the end can a project executing company gain from this?

The corresponding section in the concept of the example project will be as follows.

  1. Project Justification

    12.1. For customer:
    12.1.1. Increased order processing performance by 2 times.
    12.1.1.1. "As Is": 2500 orders / year for 8 people. * Hour.
    12.1.1.2. "To Be": 2500 orders / year for 4 people * hour.
    12.1.1.3. Savings: 2500 * 4 * $ 50 = $ 500,000 per year.
    12.1.2. Increase the speed of control
    12.1.2.1. "As Is": Monthly Reporting.
    12.1.2.2. "To Be": Reporting on-line.
    12.1.3. Increase customer satisfaction:
    12.1.3.1. Reduction in order processing time by 2 times.
    12.1.3.2. Reducing the time to search for necessary documentation by 10 times
    12.1.3.3. Increase the efficiency of updating the catalog 10 times. 12.2. For an executive company:
    12.2.1. High strategic value. Gives steady increase in the market and a gain of the new market.
    12.2.2. Financial value is above average. Expected revenues from the project are at least 1.3 times higher than expenses.

findings

Effective processes of program project initiation largely determine its future success. Insufficient attention to this phase of the project inevitably leads to significant problems in planning, implementation and completion.

The project concept is the key document that is used to make decisions throughout the project, as well as during the acceptance phase, to confirm the result.

The priority of the project is determined on the basis of an assessment of three indicators:

  • Financial value.
  • Strategic value.
  • The level of risk.

Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

software project management

Terms: software project management