3.1 Initiation of the project. Project Priority Management

Effective processes of initiating a software project at least half determine its future success. Lack of attention to this particular phase of the project inevitably leads to significant problems in the planning, implementation and completion of the project.

Initiation consists of processes that facilitate the formal authorization of the start of a new project or project phase. Initiation processes are often performed outside the project and are associated with organizational, program, or portfolio processes. During the initiation process, the initial description of the content and resources that the organization plans to invest are clarified. At this stage, the project manager is also selected, if he has not yet been assigned, and the initial assumptions and limitations are documented. This information is entered into the project charter and, if approved, the project is officially authorized.

Project Charter [1] is a document issued by the project initiator or sponsor, which formally legitimizes the existence of the project and gives the project manager the authority to use organizational resources in project operations.

In Russian practice, this document is more often called the Project Concept. The concept (from lat. Conceptio - understanding, system), a certain way of understanding, interpreting any object, phenomenon, process, the main point of view on the subject, etc., is a guiding idea for their systematic coverage.

In a company that decides on the start of a software development project, there should be a unified system of criteria for assessing its significance. The system of criteria should allow choosing from the set of possible projects for realization the most priority ones for the company.

The priority of any project should be determined on the basis of an assessment of its three characteristics:

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

The scale for assessing the financial value of the project may look as follows:

• High. Expected payback up to 1 year. The expected income from the project is at least 1.5 times higher than the costs. All assumptions in conducting these assessments are clearly justified.
• Above the average. Expected payback of the project from 1 year to 3 years. Expected revenues from the project are at least 1.3 times higher than expenses. Most of the assumptions in conducting these assessments have certain grounds.
• Average. The project allows to improve the production efficiency in the Company and potentially can reduce the company's expenses by at least 30%. A project may have information value or help to better control the business.
• Low The project slightly reduces the company's expenses by at least 10% and provides some improvements in production performance.

For example. The financial value of software development projects, implementation or maintenance projects that are carried out in accordance with concluded commercial contracts can be assessed as high. A project to develop product functionality in line with market requirements, initiated by a product manager based on an analysis of marketing, consulting, sales and technical support offers, can get a higher-than-average financial value estimate, and technological process change projects or internal automation projects can have average financial value. .

Financial value alone is not enough to determine the priority of a project. For example, no software company will undertake to automate illegal drug trafficking if it does not fit its business strategy. Therefore, an important indicator of the priority of the project is its compliance with the strategic goals of the company.

The scale of assessment of the strategic value of the project may be as follows:

• High. Provides a strategic advantage, gives a steady increase in the market or allows you to enter a new market. Solves significant problems common to most important customers. Repetition by competitors is difficult or will require from 1 to 2 years.
• Above the average. Creates temporary competitive advantages. Meeting commitments to many important customers. Competitive advantage can be maintained for 1 year.
• Average. Maintained market confidence in the company. Increases the opinion of customers about the quality of services provided or contributes to the fulfillment of obligations to several customers. Competitors already have or are able to repeat new opportunities within a year.
• Low Strategic impact is absent or insignificant. Impact on customers is not significant. Competitors can easily replicate project results.

The third mandatory indicator of a project’s priority should be its risk assessment. No project that has even the highest rating of financial profitability will not be put into production if the achievement of this super-profit has minimal chances.

An approximate scale for assessing the risk level of a project may be as follows:

• Low. Project objectives and requirements are well understood and documented. The scale and scope of the project are clearly defined. Resources required qualifications are available in full. The developed systems will not require a new technological platform.
• Average. The objectives of the project are defined more or less clearly. Good understanding of system requirements. The scale and scope of the project are well defined. Resources required qualifications are available mainly. Systems are created on a new, but stable technological platform.
• Above the average. The goals of the project are not clear enough. The tasks of the system or business application are not fully understood. Understanding the scope and scope of the project is not enough. Resources required qualifications are very limited. Systems are created on a new technological platform, doubts about the market stability of the platform.
• Tall. The goals of the project are fuzzy. The main functional components of the system are not defined. The scale and scope of the project is incomprehensible. Resources required qualifications are practically absent. Systems are created on a new technology platform, in respect of which there is very little clarity. Technologies have unconfirmed stability.

If a company pays little attention to managing the priorities of its projects, then this leads to an overabundance of ongoing projects, overworking performers, constant work-outs and overtime, and, as a result, to low production efficiency. When starting a new project with a high priority, the company must stop or close less significant projects to provide the new project with the necessary resources, rather than trying to do everything at once due to the intensification of work, as a rule, this does not work.

Project concept

Every project should have a concept. If the project is small, then a few paragraphs are often enough to present the concept. However, launching a project without a concept is the same as sending a ship to the sea without defining a destination for it.

The concept of the project is developed on the basis of the analysis of business needs. The main function of the document is the confirmation and coordination of a common vision of goals, objectives and results by all project participants. The concept determines what and why is being done in the project.

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. It contains, as a rule, the following sections:

• Project name
• Project Goals
• Project results
• Assumptions and limitations
• Key actors and stakeholders
• Project Resources
• Timing
• Risks
• Acceptance criteria
• Project Justification

As an example, which will illustrate the theoretical presentation of the fundamentals of project management, let’s take a real-life software development project to automate one of the divisions of a large manufacturing company. Let's call it "Automated system for the sale of documentation."

Brief legend of the project. The customer of XYZ OJSC is one of the leading manufacturers of complex technical products. Department "123", part of JSC "XYZ", is responsible for the sale of additional supporting documentation for JSC clients.

Additional documentation is not included in the standard delivery, since the owner of this technical product does not always operate it himself, but puts it into operation by another company, which becomes a client of XYZ, and buys operational documentation from it. Repair and maintenance of a specific product can be performed by a third company, which already needs detailed technical documentation on repair and maintenance. She also becomes an XYZ customer and buys the required products from her.

The main function of the “123” department is to receive and process orders for additional documentation, according to the catalog sent annually. In connection with the relocation of the “123” department to the new building, the task was set to develop and supply a system that automates the main activity of the “123” department.

The text of the document Concept of the project, which will be cited as an example, we will highlight the background color.

Objectives and results of the project

Project goals should answer the question why this project is needed. The objectives of the project should describe the business needs and objectives that are solved as a result of project execution. Project goals can be:

• Changes in the Company. For example, the automation of a number of business processes to improve the efficiency of the main production activities
• Implementation of strategic plans. For example, the conquest of a significant share of the growing market due to the withdrawal of a new product.
• Execution of contracts. For example, custom software development.
• Solving specific problems. For example, the refinement of a software product in order to bring it in line with changes in legislation.

Objectives should be significant (aimed at achieving the strategic goals of the Company), specific (specific to this project), measurable (ie, have verifiable quantitative estimates), real (achievable). A clear definition of business goals is important because it significantly affects all processes and decisions in a project. The project should be closed if it is recognized that the achievement of the goal is impossible or has become inappropriate. For example, if the real costs of the project will exceed the future revenues from its implementation.

Project results answer the question of what should be obtained after its completion. Project results should determine:

• What kind of business benefits the customer will receive as a result of the project.
• What product or service. What exactly will be produced at the end of the project.
• High-level requirements. Brief description and, if necessary, key properties and / or characteristics of the product / service.

It should be remembered that the results of the project should be measurable. This means that when evaluating the results of a project, it should be possible to conclude that the results specified in the concept are achieved or not.

The relevant section of the document is the concept of a project for creating an “Automated System for the sale of documentation” as follows.

1. Objectives and results of the project

   1.1. The aim of the project is to increase the efficiency of the main production activities of the “123” department.
   1.2. Additional objectives of the project are:
   1.2.1. Establishing long-term relationships with an important customer of XYZ OJSC.
   1.2.2. Entry into a new promising market for modern B2C systems.

2. Project results should provide:

   2.1. Reducing the cost of processing applications.
   2.2. Reducing the processing time of applications.
   2.3. Improving the efficiency of access to information on product availability.
   2.4. Improving the efficiency of access to information about the passage of applications.
   2.5. Improving the reliability and completeness of storing information about applications received and the results of their processing.

3. Project products are:

   3.1. Application software and user documentation.
   3.2. Basic software.
   3.3. LAN equipment, workstations, servers and operating system software.
   3.4. Pre-commissioning and commissioning.
   3.5. Training users and system administrators.
   3.6. Maintenance of the system at the stage of trial operation.
   3.7. Transfer of the system to industrial operation.

4. The system should automate the following functions:

   4.1. Authorization and user authentication.
   4.2. View the product catalog.
   4.3. Search for products in the catalog.
   4.4. Order selected products.
   4.5. View order status information.
   4.6. Informing the client about the change in the status of the order.
   4.7. View and order processing by executors from the sales service.
   4.8. View statistics on receipt and processing of orders for the period.
   4.9. Preparation and maintenance of product catalog.

Assumptions and limitations

This section describes the initial assumptions and limitations. Assumptions are usually closely related to risk management, which we will discuss below. In software development, it is often necessary to formulate risks in the form of assumptions, thereby transferring it to the customer. For example, when evaluating a design and implementation project under a fixed-price scheme, we must write down the assumptions that the cost of licenses for third-party software will not change before the project is completed.

Restrictions, as a rule, reduce the ability of the project team to choose solutions. In particular, they may contain:

• Specific regulatory requirements. For example, mandatory product certification, services for compliance with certain standards.
• Specific technical requirements. For example, the development for a given software and hardware platform.
• Specific requirements for the protection of information.

In this section, it is also appropriate to formulate those system requirements that can be expected by the customer by default, but are not included in the scope of this project. For example, a clause may be included in this section that the development of a software interface (API) for future integration with other customer systems is not part of the project’s objectives.

The content of this section for our sample project is as follows.

1. Assumptions and limitations

   5.1. Application software engineering is performed using UML1.
   5.2. Software development tool is Symantec Visual Cafe for Java2.
   5.3. As an intermediate software for maintenance and support of the catalog, OO DB Poet 3 is used.
   5.4. The load on the system should not be more than 100 concurrent users.
   5.5. The scope of the project does not include:
   5.5.1. Protecting the system from deliberate hacking.
   5.5.2. Development of B2B API and integration with other systems.

Key actors and stakeholders

One of the tasks of the project initiation phase is to identify and describe all of its participants. According to [1], project participants include all stakeholders (stakeholders), individuals and organizations, such as customers, sponsors, a performing organization, who are actively involved in a project or whose interests may be affected during the execution or completion of a project. Participants can also influence the project and its delivery results.

As a rule, key participants of a software project include:

• A project sponsor is a person or group of persons providing financial resources for a project in any form.
• The project customer is the person or organization that will use the product, service, or project result. It should be noted that the customer and the project sponsor do not always coincide.
• Project results users .
• The project curator is the representative of the contractor authorized to make a decision on the allocation of resources and changes in the project.
• The project manager is the representative of the contractor responsible for the implementation of the project on time, within the budget and with the specified quality.
• Collaborators of the project. Subcontractors and suppliers.

The content of this section in the concept-example will have the form.

1. Key actors and stakeholders

   6.1. The project sponsor is V. Vasiliev, Director of the Information Department of XYZ OJSC.
   6.2. Customer - Head of the Department "123" F. Fedotov
   6.3. Automated system users:
   6.4. Clients of OJSC "XYZ" (search and order documentation).
   6.5. Management of JSC "XYZ" (analysis of the activities of the Department "123").
   6.6. Employees of the production departments of JSC "XYZ" (catalog maintenance).
   6.7. Employees of the Department "123" (processing applications and supplying documentation).
   6.8. Employees of the Department of Informatization of JSC "XYZ" (system administration).
   6.9. The curator of the project is the head of the custom development department I. Ivanov.
   6.10. Project Manager - Leading Specialist of the Department of Custom Development of MP P.Petrov.

2. Subcontractors:

   7.1. The supplier of equipment and operating system software is Alpha LLC.
   7.2. The basic software provider is Beta LLC.

Resources

In order to understand how much the implementation of a software project will cost, it is necessary to identify and evaluate the resources necessary for its implementation:

• Human resources and staff qualification requirements.
• Equipment, services, consumables, software licenses, critical computer resources.
• Project's budget. Plan the costs and, if necessary, the estimated income of the project, broken down by items and phases / phases of the project.

The specifics of a software project is that human resources make a major contribution to its cost. All other costs are usually insignificant compared to these costs. We will talk in detail in the following lectures on how to approach the estimated labor costs for the implementation of a software development project. At the initiation phase, a labor cost estimate with an accuracy of -50% to + 100% is considered good [2].

It must be remembered that in addition to directly programming in a software development project there are many other processes that require resources of appropriate qualification, and programming itself amounts to only a quarter of all costs. The distribution of labor costs for the main production processes in the modern software development process looks on average as follows:

Figure 14. The distribution of labor costs for the main production processes in software development

Therefore, if you need to write 10 KSLOC (thousands of lines of source code) to implement the required functionality in the project, and your programmers write an average of 100 SLOC per day, then the total effort for the project will not be 100 people * days, but not less than 400 people * days. The remaining resources will be required for the analysis and specification of requirements, design, documentation, testing and other design work.

Before determining the size and composition of the project team for our example, we need to make an assessment of the complexity of software development. In our case, such an expert assessment was based on the cost of warranty support at the stage of trial operation of 9000 people * hour. Based on the empirical curve of B. Boehm (Figure 15), the number of the team, which is close to optimal, was 10 people, of which

1. Project Resources

   8.1. Staff Requirements
   8.1.1. 1 - project manager
   8.1.2. 1 - technical leader (architecture, design),
   8.1.3. 1 - systems analyst (requirements, test design, documentation),
   8.1.4. 4 - programmers (taking into account the work on configuration management),
   8.1.5. 3 - tester.
   8.2. Material and other resources
   8.2.1. Configuration Management Server and Version Control System Support
   8.2.2. 2 server complexes (for development and testing):
   8.2.3. Application server with BEA Weblogic AS installed
   8.2.4. Server operational database with installed Oracle RDBMS
   8.2.5. Directory server with installed OODB "Poet"
   8.3.Licenses for development and testing tools:
   8.3.1. Oracle Designer - 1 license
   8.3.2. Symantec Visual Cafe for Java - 5 licenses.
   8.3.3. IBM Rational Test Robot (1 developer license + unlimited client license).
   8.4. Expenditure budget of the project4
   8.4.1.Development and maintenance of application software:
   8.4.1.1. 9000 people * hour * $ 40 = $ 360,000
   8.4.2. Supply of equipment and operating system software:
   8.4.2.1. 3 servers * $ 10,000 = $ 30,000
   8.4.3. Supply of basic software:
   8.4.3.1. BEA Weblogic AS $ 20,000
   8.4.3.2. Oracle RDBMS $ 20,000

Total: $ 430,000

1 The project started in 2000, the topic of UML was well known at that time, and even those who believed that the source code could be generated from the UML model remained.

2 Such was the requirement of the Customer, because this tool was used by programmers who were supposed to transfer the system to maintenance.

3 Another example of a hot topic and unfulfilled hopes is object-oriented databases. Licenses for this database have already been purchased from the project customer and he really wanted to get a return on this investment. Therefore, its use in the project has become one of the requirements. Fortunately, we managed to be convincing enough to justify the need to additionally use Oracle RDBMS for solving transactional problems. I described in detail what this led to in my book: S. Arkhipenkov, "Leadership of the Software Development Team. Applied Thoughts," Moscow, 2008.

4 We in this section estimate the cost of the project. The definition of the sales price of the project is not included in the scope of this course.