Initiation of the project 3. The first steps to create a project

3.1. Adaptation of the project life cycle model

In this tutorial on managing IT projects, the life cycle model of information systems (IR life cycle ) described in GOST R ISO / IEC 15288 is used as a conceptual framework. In accordance with this standard, launching each new project involves creating (or adapting an existing ) model of life cycle consisting of stages.

The process of creating (or adapting an already existing) life-cycle model begins with defining the goals and results of each of the stages that form the structure of work for the detailed modeling of IT implementation processes. [ten]

Based on the assumptions of the basic standard, as well as the standard stages of the life cycle IT and the adopted sequence of their implementation, the authors propose the following life cycle model IT, which determines the sequence of presentation of the material in the book.

1. Project Planning

2. Design

3. Development and implementation

4. Operation and support

5. Recycling and updating

The table below presents the objectives of each of the selected stages of life cycle (see table. 3.1).

The stages are the stages of the life cycle of the information system and are not identical to the life cycle of the project. The product life cycle reflects what needs to be done to create, operate, maintain and dispose of the product, and the project life cycle reflects how to organize and manage work. The life cycle phase of a product may include all phases of a project life cycle (see Fig. 3.1 (a, b)), and, in accordance with GOST R ISO / IEC 15288 [10], provides for planning, evaluation and control phases, and also the decision making process - the gateway (see Fig. 3.1. (a)), through which the transition to the next stage of the life cycle of the IP takes place and which is the point of monitoring quality and the point of deciding whether to continue the project [10]. It should be noted that planning, evaluation and control are characteristic of any management cycle (for example, the Deming cycle). Thus, their use, including at the “ Operation and Support ” stage, which is of a pronounced operational (non-project) character, is quite justified.

Table 3.1. The objectives of the stages of the life cycle of the information system

Considering each stage of the life cycle IT as a separate project allows (in fact, makes it only possible) to apply the incident wave method of planning, which significantly reduces the riskiness of the project and increases the chances of success [9].

Fig. 3.1. (a, b) Examples of the relationship between the life cycle of the information system and the project life cycle

At the same time, the processes carried out within the framework of one stage of the life cycle of IT, can have interrelations both within this stage and with the processes of the other stages. Obviously, to successfully achieve the objectives of the project, it is necessary not only to manage each process separately, but also to ensure an integrated approach to management, taking into account interconnections, interdependencies of both individual processes and groups of processes.

In order to structure the project management processes, it is customary to divide into areas of knowledge. Below are the areas of knowledge that make up the project management processes. The proposed list is based on the recommendations of the best world practices and is contained in the project management standard [1,10, 23].

Integration Management

Content management

Time management

Cost management

Quality control

Management of risks

Human Resource Management

Communications management

Configuration management

A description of the content of each of the above areas of knowledge and the corresponding processes is given in Table. 3.2.

Table 3.2. Areas of knowledge of project management

Each of the stages of the life cycle of IT and the life of the project provides a set of tasks.

Within specific projects, the proposed stages of the life cycle IT, as well as individual processes of the life cycle IT, can be individually selected, identified and, if necessary, modified to achieve the modified goals and results of the respective stages.

Changes made should be documented. The general requirements for the modification procedure are as follows: any new life cycle process is defined and documented in terms of its purpose, goals, and results. Responsible for this kind of modification is, as a rule, the head of the relevant project. At the same time, the approval of an adapted, abbreviated or augmented life cycle model of an IP is usually performed by a project management office or another organizational unit whose responsibilities include maintaining the integrity and relevance of corporate project management methodology [8].

The above procedure and template for documenting the life cycle modification of IT is one of the possible options for designing the corresponding actions on the life cycle IT.

3.2. The procedure for adapting the life cycle model of IC

When adapting the life cycle model of IT in the interests of the organization or project in accordance with the applicable policies and procedures, the following actions should be performed.

1. The project manager (PM) identifies and documents the circumstances affecting the adaptation. These impacts include (but are not limited to) the following:

o stability and diversity of the functioning environment;

o commercial or operational risks related to interested parties;

o novelty, size and complexity;

o start date and duration of use;

o integrity issues such as security, security, privacy, ease of use,

o availability;

o newly emerging technological capabilities;

o budget profile and available organizational resources;

o readiness to provide services by supporting systems.

2. In the presence of properties that are critical to the system, the project manager should take into account the life cycle structures that are recommended or established as mandatory standards corresponding to the field of criticality.

3. Next, the project manager collects input from the following project stakeholders:

o copyright holders of the system;

o interested parties to the agreement entered into by the organization;

o parties contributing to organizational functions .

4. The project manager defines a new (modified) model of the system life cycle in terms of stages, their purpose, goals and results, which are achieved as a result of applying life cycle processes within each stage.

5. The project office decides on the adaptation of the base model.

6. The life cycle modification of the information system acquires a local (for one project and for one (sub) system) or corporate-wide nature at the decision of the project office, based on the results of testing the proposed RP of the modification.

Table 3.3. Template adaptation of the information system life cycle model

3.3. Feasibility Study Development

Traditionally, the main objective of preparing a feasibility study of an IT project is to obtain funding for the implementation of the relevant initiative. In addition, a correctly constructed feasibility study can solve the following tasks:

• приоритизация проектов в условиях ограниченных финансовых, человеческих и прочих ресурсов;
• определение совокупности организационно-технологических мероприятий по обеспечению заявленных бизнес-выгод от реализации проекта;
• обеспечение заинтересованности руководителей бизнес-подразделений в проекте;
• формирование основы для оценки соответствия результатов проекта и первоначальных планов.

Согласно последним исследованиям 75% компаний ставит именно такие цели при подготовке ТЭО , в то же время всего лишь 40% из них считают, что используемые ими методы позволяют получить корректную оценку эффективности внедряемого ИТ-решения [7].

Помимо обозначенных задач ТЭО может обеспечивать входную информацию для устава проекта, рассматриваемый в данной книге как ключевой документ интегрированного управления проектом. Для того чтобы ТЭО обеспечивал качественную информацию, рекомендуется следующим образом структурировать идентифицированные бизнес-выгоды ИТ-проекта (см. табл. 3.4.).

В соответствии с предлагаемым подходом [7] бизнес-выгоды можно классифицировать по двум факторам: (1) характеру воздействия на бизнес и (2) степени определенности. Таким образом, каждая выгода по проекту размещается "на пересечении" соответствующих значений двух обозначенных факторов.

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

1. Создание новых возможностей : функциональность информационной системы, ранее не доступная компании, ее контрагентам или иным заинтересованным сторонам.

2. Повышение эффективности операций :функциональность новой информационной системы позволяет выполнять существовавшие до нее операции гораздо более эффективно.

3. Отказ от операций : информационная система позволяет отказаться от выполнения операций, утративших свою актуальность для бизнеса компании в связи с изменением бизнес-процессов.

Таблица 3.4. Матрица структурирования выгод ИТ-проекта (7])

После определения характера воздействия необходимо классифицировать каждую бизнес-выгоду по степени определенности (от менее определенных к более определенным): наблюдаемые (качественные), измеримые, количественные, финансовые.

1. Качественные : выгоды, которые могут быть зафиксированы на уровне экспертного мнения или суждения. В то время как данный тип выгод вполне допустим, необходимо всегда предупреждать ситуацию, когда без четкого значения выгоды на этапе планирования очень сложно определить степень ее реализации на момент принятия результатов проекта. В связи с этим рекомендуется разрабатывать четкие критерии реализации качественных выгод в самом начале проекта и, по возможности, собирать дополнительную информацию для "переноса" качественных выгод в более объективные категории.

2. Измеримые :выгоды данного типа поддаются измерению. В распоряжении аналитика есть инструменты и техники, например, ключевые показатели эффективности, позволяющие измерить их значение до внедрения. Для данного типа бизнес-выгод характерна невозможность оценить значение соответствующего показателя после внедрения.

3. Количественные :аналогично измеримым, количественные выгоды характеризуются наличием показателей, позволяющих измерить их значение до выполнения проекта. Но, в отличие от измеримых, значение показателей количественных бизнес-выгод на момент окончания проекта можно оценить с высокой степенью точности.

4. Финансовые :это тип бизнес-выгод, которые могут быть выражены в терминах финансовых показателей. Отнесение бизнес-выгоды к данной категории должно производиться только в том случае, если в распоряжении аналитика имеется достаточно достоверная информация о финансовой оценке соответствующих показателей. Очевидно, финансовые выгоды есть результат "обогащения" количественных бизнес-выгод финансовыми данными. Агрегированные финансовые выгоды проекта образуют базу для построения финансовой модели проекта (ROI-модель) и расчета инвестиционных показателей: NPV, IRR , периода окупаемости.

Выбор той или иной категории для конкретной бизнес-выгоды производится на основе доступной информации о ней до момента реализации инвестиций. Каждая бизнес-выгода на момент ее идентификации относится к наименее определенной категории - наблюдаемая. По ходу анализа необходимо максимальное количество бизнес-выгод перенести в финансовую категорию для построения экономической модели окупаемости проекта, кроме доходной части, в которой должна быть отражена и расходная. В качестве инструмента оценки стоимости проекта и системы авторы рекомендуют использовать модель совокупной стоимости владения системы ( TCO ), рассмотрение которой будет произведено в разделе, посвященном управлению стоимостью проекта.

3.4. Формирование бизнес-цели проекта

Бизнес-цель - это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится "просто выдать продукт", а не достичь какой-либо тактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель   проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта ).

Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.

The business objective should be sufficiently weighty for the organization to decide to proceed to the development of the project charter, the document, in accordance with the best practices of the initiating project. As a tool to determine the need for the project, a feasibility study , or business case, of the project can be used .