Mastering Opportunities and Risks in IT Projects (Book Excerpt)

Identifying, anticipating and controlling opportunities and risks: A model for effective management in IT development and operation.

Management systems show the management objectives (in relation to a specific purpose), proven methods for achieving the objectives and the associated control and monitoring mechanisms. The purpose can be the management of a company, an IT project or just compliance with a quality, environmental or information security standard. This book uses a model to describe how the fundamentally necessary core process of risk management works within such a management system. Its main feature is the cyclical repetition of the identification and evaluation of opportunities and risks, which leads to necessary control measures influencing them and to the subsequent implementation of measures to improve the effectiveness and efficiency of the management system.

Each cycle begins with the definition of key goals for the purpose intended and a review of the decisions already made. This is followed by the identification of influencing factors that threaten or even favor the achievement of goals - and their assessment. As the basis for focusing on key goals and acute threats, this step is an important prerequisite for economic risk management. 

In order to find influencing factors that favor or threaten the achievement of the selected goals, the combination of a methodical cause-and-effect analysis with own empirical values is recommended. The risk portfolio comprises the set of all influencing factors. After an assessment of their probability of occurrence as well as of the amount and type of potential damage that may occur if a goal is not achieved, this enables the focus to be placed on a subset of the threats, which in the model described is referred to as the risk profile.

Model for managing opportunities and risks

The risk profile reassessed in the respective cycle forms the basis for management decisions on the treatment of risks. This treatment can, for example, consist of taking out insurance (risk transfer), outsourcing risky areas from the IT project under consideration to other parts of the organization (restructuring) or implementing and following up measures to actively reduce risk. If, in individual cases, the risk owners do not consider it necessary to reduce the risks by means of a transfer, restructuring or measures, this must be documented as acceptance of the residual risks.

In the final step of each cycle, the measures that can be taken to improve the effectiveness of risk management and its cost/benefit ratio should be examined. This includes a review of all components of the model such as processes, methods, metrics and scales for evaluation, documentation, etc.

Considerable potential for improving the management model lies in making knowledge about general or organization-specific threats to the goal types explicit - and in permanently adapting this explicit knowledge to changes in the threat situation, for example. One way of implementing this explicit knowledge is the creation and maintenance of sets of rules that submit questionnaires to the people responsible for risk analysis and from whose responses corresponding entries in the risk profile result. However, these suggested values must be validated and possibly corrected on the basis of own human judgment and intuition. A further improvement is foreseeable as soon as machine learning systems can be used for risk analysis purposes.

It is possible to carry out risk management both effectively and efficiently: With good methodology, threats can be noticeably mitigated. Thereby risk management becomes effective. The avoided damage results in a benefit that can be calculated and placed in relation to the required effort. This results in a measure of efficiency. As with any other management process, both effectiveness and calculability of efficiency are an essential basis for optimization.

The book is available as e-book, paperback and hardcover (directly in the Tredition book shop incl. reading sample - or in bookstores).  

Book Series "Increasing Productivity in Software Development"

The PASS Group has been using key figures as the basis for its IT management in more than 10 different application landscapes with more than 500 customers and over 250,000 users for several years and is now publishing its experiences in the form of a series of books. In some areas, the regularly collected key figures demonstrate a 100-fold increase in delivery productivity compared to just a few years ago and they show in which areas further improvements are possible.


Why measure productivity?

IT has already changed almost all areas of life through fundamental innovations. Our future will be dominated by virtualization and smart helpers, i.e. things equipped with intelligence. Software is the stuff of innovation. Software development is a key competence.

Productivity and quality are critical success factors for companies developing software. Only with suitable measuring methods, regular measurements and rapid feedback of the measured values to the team and its management can the effort of planned developments be reliably determined and productivity and quality be continuously improved.

Part 1: "Productivity and Performance Measurement - Measurability and Methods"

Book Series "Increasing Productivity in Software Development"

The first book in the series first explains a practicable definition of productivity for software development and thus shows the conditions under which productivity can be measured at all. It describes the ISO/IEC 14143 standard as an important common basis for all modern function-oriented measurement methods. Some methods are explained in detail and compared with their advantages and disadvantages on the basis of practical examples - tried and tested as well as new ones. The book deals with the automatability of measurements, but also points out their limits, the exceeding of which leads to invalidity measurements due to a strong orientation towards design features instead of application cases.

Another topic is the influence of complexity on the scope to be measured, the different consideration of complexity through different measurement methods and the limits of measurability through function-oriented metrics, for example in systems with above-average algorithmic complexity.

Part 2: "Management Model, Cost Estimation and KPI Improvement"

The second book describes a model based on three key performance indicators (KPIs): Productivity (measured using the measurement methods described in the first book), cost and quality. It explains its cyclical survey, analytical evaluation and indicators, for example by comparing productivity and quality over time or as a result of methodological analyses of the causes of errors, which lead to improvement measures in important areas of influence in software development, so-called key performance areas (KPAs). In order to be able to assess the benefits of the measures in advance, it provides empirical values as well as a method for calculating their effectiveness. The model described is a navigation tool that always shows management in which direction and at what speed it moves with regard to its three KPIs.

The books are available as e-book, paperback and hardcover (in the PASS book shop or at Amazon.com).

Direct and indirect Cost Estimation Methods (3)

Indirect Estimations by measuring the Functional Size

A different type of an indirect estimation is determining the functional size (instead of Story Points) and relating it to an empirical value describing which size can be implemented with specific personnel costs (often called productivity or efficiency). The basics for measuring the functional size are defined in the industry standard ISO/IEC 14143. They require the refinement of user stories to use cases.

Sample Use Case Diagram

A use case stands for a system behavior perceptible by an actor from outside of the system boundaries. Actors can be human system users as well as other systems or machines (hardware or software). An example is the use case diagram of a (highly simplified) Internet Booking Engine for flights shown in the accompanying picture. Within the system boundaries (shown as a rectangle with the label "Internet Booking Engine”) use cases are represented by ellipses. They are related to (used by) actors, which in the example below are a traveler and a Computer Reservation System (CRS). Their relation is indicated by lines.

Each use case stands for actions which can be described by base functional components (BFCs) respectively elementary processes. The use case “search flight” could, for example, consist of the following (simplified) elementary processes:

1. Traveler calls the dialog Flight Search.
2. Traveler enters the departure date.
3. Traveler enters the first letters of the destination (name or code).
4. System looks up for matching airports in the database and displays a list of found items showing names and codes.
5. Traveler selects a list entry and clicks on the button “Search”.
6. System sends a message of type “Flight Search Request” including the departure date and airport code to the CRS.
7. System receives a message of type “Flight Search Response” from the CRS and reads the fields departure time, arrival time, airline, flight number, class, price and currency of all flight records included.
8. System displays a table showing this information about all received flight records.

With the knowledge of these BFCs or elementary processes many measuring methods can be used to determine the functional size and, with the aid of an empirical value of the own productivity, the expected development costs.

Alternatives:

    Expert Estimations
    Indirect Estimations with Story Points

Book recommendation: "Cost Estimation in Agile Software Development"

Direct and indirect Cost Estimation Methods (1)

Expert Estimations

A proven method to approximate the costs for implementing a user story is the expert estimation. One or more experts independently estimate based on previous experience with similar tasks. Since individual experience can differ to a high degree and depends on the own capabilities, it is obvious to use the average over all estimations. In addition to this subjectivity, another problem of the method is that experts mostly are members of development teams and cannot productively contribute to the development process while performing their estimation.
 
A derivative of the expert estimation is the Delphi method, where a moderator first presents details of the user stories to be estimated to all involved experts. Subsequently, they perform an individual estimation, completely independent from each other. Then the moderator evaluates, presents the results and thereby points out discrepancies – all with respect to anonymity. Discussions are undesirable to prevent an influence on group dynamics through dominant experts. Every expert has the opportunity to rethink and change his estimation. This process is repeated until the discrepancies do no longer exceed a tolerance threshold. An advantage of the Delphi method is the iterative refinement of all expert estimations and the resulting higher accuracy. A disadvantage is the high time commitment of the experts.

Alternatives:

    Indirect Estimations with Story Points
    Indirect Estimations by measuring the Functional Size

Book recommendation: "Cost Estimation in Agile Software Development"

Direct and indirect Cost Estimation Methods (2)

Indirect Estimations with Story Points

Any direct estimation (see: Expert Estimations) depends on the estimator’s individual skills and experiences and does usually not consider the capability of the team planned for the development. Contrary to this, indirect methods first determine the size of the objects respectively requirements to be developed and then put it in relation to empirical values of, ideally, the same team from earlier sprints. 

In case of the story points method, estimators rate the size of user stories relative to each other and not in an absolute unit of measurement. Example: “The selection of the destination airport and the date is a one. Relative to this, the query for available flights is a three. Accordingly, booking a selected flight is an eight.” The scale of story points is aligned to the Fibonacci sequence: 1, 2, 3, 5, 8, 13, and so on. This avoids many discussions about details and makes decisions between the valid numbers easier. At the same time it is obvious that, using this scale, the accuracy of estimations decreases with the increasing size of stories.

The calculation of the prospective development costs on basis of story points also requires an empirical value of how many story points the team can develop per increment or sprint under comparable conditions. This empirical value is called velocity and is updated after each completed sprint by determining the size of all successful developed stories in relationship to the required time.

Advantages of the story point method are its quick use and that it is being based on the current team performance instead of the ability of individual experts. Due to the periodical recalibration, velocity can be fit to changes in team composition or other basic conditions within few sprints.

A disadvantage is the detail level of the object to be estimated: a user story which describes a requirement by only one sentence. Any unexpected complexity first discovered during the implementation often results in exceeding the estimated effort.

Alternatives:

    Expert Estimations
    Indirect Estimations by measuring the Functional Size

Book recommendation: "Cost Estimation in Agile Software Development"

Agile Principles are Risk Mitigation Methods

Many risks of commercial software development can be mitigated by the principles of agile development:

Risk: The requirements of the customer are not covered completely. His expectations for example regarding usability have not been fulfilled. 
Measures: The product is developed incrementally, with the cycles being as short as possible. The result of each cycle is operable software, which can be checked by the customer regarding the fulfillment of his expectations. The customer, in particular his business and technical professionals, collaborate closely and intensively with the development team.


Risk: Objectives and requirements of the customer change, before the development is completed, for example as a reaction to unexpected market changes.
Measures: One principle of the Agile Manifesto is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” Thus, agile software development is generally characterized by the willingness to consider new or changed requirements. However, this does not preclude a consensus between the contract parties regarding the commercial effects of such changes. 

Risks: Wrong assessment of the development progress, delays due to communication problems, loss of know-how by staff turnover.
Measures: In agile development processes these risks are mitigated by a high level of teamwork. In short daily team meetings problems can be addressed, the progress can be estimated together, pending tasks can be assigned or even tasks in progress can be re-assigned if it seems reasonable. The avoidance of too rigid role and task assignments makes the team robust toward the loss of individuals. 

Risk: Additional expenses due to quality deficiencies which have been discovered too late. 
Measures: One characteristic of agile development are automated processes for the daily build of an executable system, where an initial code analysis is performed, followed by functionality checks of particular components using unit tests and, if possible, the execution of scripted test cases. 


Risk: Invalid planning of the manpower required to fulfil a development contract within the agreed time.
Measure: This risk can be countered by applying a cost estimation method with accuracy improving with every retrospective. Such methods are described in detail in my book "Cost Estimation in Agile Software Development".

The Book about Cost Estimation in Agile Software Development

Agile software development and a binding agreed delivery date are not mutually exclusive at all. On the contrary, the principles of the Agile Manifesto are well-proven measures to mitigate the typical risks of development projects with binding regulations.

Crucial for the achievement of project goals is a reliable plan which can be created without significant expense and readjusted flexibly in case of changed requirements. Under these conditions, indirect cost estimations on basis of functional size measurements are a proven practice. They require the size of the functional requirements as an input value, determined by precise rules, as well as an empirical value of the own productivity, measured after earlier sprints.

To the Shop

For the determination of functional size, methodological knowledge and expertise is required regarding the selected method, for example Function Point, COSMIC or Data Interaction Point method, along with a sufficient specification of requirements, for example by described use cases and elementary processes. Under these conditions, the resulting value is a valid key figure of the functional requirements’ size. It is independent from the individual performing the estimation. Repeated estimations of the same requirements always result in the same value.

An empirical value of the own productivity, that is the functional size which can be typically implemented by the team with given personnel costs, is required in addi-tion. It can be measured and updated within the scope of regular retrospectives of completed increments, sprints or releases. Thereby, the implemented functional size is set in relation to the arising personnel costs. The functional size is determined by counting – depending on the method – elementary processes or data elements. With an appropriate mapping to structural characteristics of the system, this counting process can be automated. A such counting program, once implemented, can quickly measure the total size of the system and, by comparing the current size with the previous measurement, return the growth of the functional size resulting from the last development process. 

Regularly measured and compared values of productivity and quality - in the simplest case the number of production defects – aid in recognizing any need for action and allow to verify the effectivity of implemented improvement measures.

This book illustrates, how size metrics can be utilised profitably in software development processes oriented towards agile values. It points out differences and restrictions, how the accuracy of cost estimations can be increased with each sprint and examines the feasibility of automated measurements. It is available as eBook, paperback and hardcover at most bookshops, for example at Amazon.com.