3. Project Initiation 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. 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, consequently, to low production efficiency. When starting a new project with high priority, the company must stop or close less significant projects to provide the new project with the necessary resources, and not try 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 customer about changing 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.

5. Assumptions and limitations

   5.1. Application software engineering is performed using UML ¹ .
   5.2. Software development tool is Symantec Visual Cafe for Java ² .
   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.

6. 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.

7. 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].

Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом:

Рисунок 14.Распределение трудозатрат по основным производственным процессам при разработке ПО

Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней. Остальные ресурсы потребуются на анализ и уточнение требований, проектирование, документирование, тестирование и другие проектные работы.

Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час. Исходя из эмпирической кривой Б. Боэма (Рисунок 15), численность команды, близкая к оптимальной, составила 10 человек, из них

8. Ресурсы проекта

   8.1. Требования к персоналу
   8.1.1. 1 — руководитель проекта,
   8.1.2. 1 — технический лидер (архитектура, проектирование),
   8.1.3. 1 — системный аналитик (требования, тест-дизайн, документирование),
   8.1.4. 4 — программисты (с учетом работ по конфигурационному управлению),
   8.1.5. 3 — тестировщика.
   8.2. Материальные и другие ресурсы
   8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий
   8.2.2. 2 серверных комплекса (для разработки и тестирования):
   8.2.3. Сервер приложений с установленным BEA Weblogic AS
   8.2.4. Сервер оперативной БД с установленной Oracle RDBMS
   8.2.5. Сервер каталога с установленной OODB "Poet"
   8.3. Лицензии на средства разработки и тестирования:
   8.3.1. Oracle Designer — 1 лицензия
   8.3.2. Symantec Visual Cafe for Java — 5 лицензий.
   8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия на клиент).
   8.4. Расходная часть бюджета проекта ⁴
   8.4.1. Разработка и сопровождение прикладного ПО:
   8.4.1.1. 9000 чел.*час. * $40 = $360 000
   8.4.2. Поставка оборудования и операционно-системного ПО:
   8.4.2.1. 3 сервера * $10 000 = $30 000
   8.4.3. Поставка базового ПО:
   8.4.3.1. BEA Weblogic AS $20 000
   8.4.3.2. Oracle RDBMS $20 000

Итого: $430 000

1 Проект стартовал в 2000 году, тема UML тогда была на слуху и даже оставались те, кто верил, что из модели на UML можно будет генерировать исходный код.

2 Таково было требование Заказчика, поскольку этот инструмент использовали его программисты, которым предполагалось передавать систему на сопровождение.

3 Еще один пример горячей темы и не оправдавшихся надежд — это объектно-ориентированные базы данных. У заказчика проекта уже были закуплены лицензии на эту базу данных и он очень хотел получить возврат от этих инвестиций. Поэтому ее использование в проекте стало одним из требований. К счастью, нам удалось быть достаточно убедительными и обосновать необходимость дополнительно использовать RDBMS Oracle для решения транзакционных задач. О том, к чему это привело, я подробно рассказал в своей книге: С. Архипенков, "Руководство командой разработчиков программного обеспечения. Прикладные мысли", Москва, 2008.

4 Мы в данном разделе оцениваем себестоимость проекта. Определение продажной цены проекта не входит в рамки данного курса.