You get a bonus - 1 coin for daily activity. Now you have 1 coin

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

Lecture




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

Stage (GOST R ISO / IEC 15288)

Stage (adapted)

Stage goal

Idea

Project planning

Evaluation of new business opportunities, development of preliminary system requirements and testing of their feasibility. Conceptual planning of the whole life cycle of IP

Development

Design

Creating a project system that meets the requirements of the acquirer and can be implemented, tested, evaluated, applied as intended, supported during the application, subsequently written off and / or updated

Production

Development and implementation

Development (customization) of the system in accordance with the requirements of the acquirer, testing of the system, implementation of relevant organizational and technical measures and deployment of supporting systems aimed at ensuring the correct operation of the implemented product

Application Application Support

Operation and support

Using the embedded product in the specified operating conditions and ensuring long-term performance. Implementation in the process of operation of logistics, maintenance and repairs, which ensure the continuous operation of the system in question and the sustainable provision of services that support its use

Withdrawal and write-off

Recycling and update

Ensuring the removal of the system under consideration and associated with it the servicing and supporting organizational and technological subsystems. Support planning for the transition to a new version of the current or a completely new 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].

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


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

Field of knowledge

Description

Processes

Integration Management

Integration management includes the processes and actions required to define, refine, combine, combine, and coordinate various project management processes and actions within project management process groups . Thus, the goal of this process is to achieve effective interaction between project management processes that ensure the achievement of project objectives. Effective interaction at the planning stage consists in forming the baseline of project 1 (project baseline), at the assessment stage - in comparison with the baseline and adjusting it in accordance with it at the control stage

1. Development of the feasibility study of the project.

2. Development of the project charter.

3. Develop a project management plan .

4. Management and management of project execution.

5. Implementing integrated change management.

6. Evaluation of project alternatives.

7. Planning for the closure of the project and the transition to the stage of operation.

8. Completion of the project.

Content management

Content management includes processes and actions that ensure the inclusion in the project of all those and only those works that are necessary for the successful implementation of the project. It is directly related to the definition and control of what is included or not included in the project [1.23]

1. Formation of the project requirements.

2. The formation of the SRI .

3. Determining the content of the project.

4. Determination of the results of all stages of RC .

5. Evaluation of the feasibility of the project requirements.

6. Confirmation of the content of the project.

7. Definition of updated system requirements.

8. Monitoring the content and scope of the project.

9. Assessment of user readiness to work in the system.

10. Planning end-user training

Time management

Project time management includes processes that ensure timely completion of the project [23]

1. Formation of the list of project works.

2. Determination of the project work sequence.

3. Evaluation of the complexity and duration of work.

4. Development of the basic schedule of the project .

5. Control and management of the project schedule

Cost management

Project Cost Management integrates processes performed during planning, budget development, and cost control to ensure project completion within the approved budget [23]

1. Estimate the cost of the project.

2. Development of project estimates.

3. Development of a basic plan for the cost.

4. Project cost management

Quality control

Project quality management processes integrate all operations carried out in the executing organization, which determine the policy, objectives and distribution of responsibility in the field of quality in such a way that the project meets the needs for which it was undertaken. Quality management is carried out through a management system that provides for certain rules, procedures and processes for quality planning, quality assurance and quality control, as well as operations for their improvement.

1. Formation of the project quality program.

2. Formation of the baseline of the project requirements.

3. Manage project requirements.

4. Implementation of quality assurance.

5. Testing.

6. Acceptance of results

Risk management

The risk management process is closely related to the overall project life cycle. In the early stages, the risks associated with the business, the project framework, the requirements for the final product and the design of this product prevail. At the implementation stage, technological risks dominate, and the role of risks associated with the support and maintenance of the system further increases. Throughout the project’s life cycle, new risks arise that require additional analysis and planning. According to GOST R ISO / IEC 15288-2005 [10], the goal of the risk management process is to reduce the consequences of the negative impact of likely events that may cause quality changes. , cost, timing or deterioration of technical specifications. During this process, the definition, assessment, processing and monitoring of risks occurring during the full life cycle are carried out, and a response is developed to each risk in terms of the implementation of appropriate measures to counter the risk or its adoption.

1. Planning risk management.

2. Risk identification.

3. Qualitative risk analysis .

4. Quantitative risk analysis.

5. Planning risk response.

6. Monitoring and risk management

Human Resource Management

Human resource management of a project is the process of ensuring the effective use of human resources of a project, which include all project participants (sponsors, customers, project team, subcontractors, company departments and other project participants [13,17])

1. Human resource planning.

2. Set the project team.

3. Assessment of accessibility.

4. Development and evaluation of the project team.

5. Organization of project infrastructure

Communications management

Managing project communications is the process of identifying and effectively providing all project participants with information about the project, as well as creating a single image of the project within the organization.

1. Identification of project participants.

2. Forming a strategy and communication plan .

3. Implement a communication plan and collect feedback

Configuration management

Configuration management is the process of managing hardware, software, data, and documentation during the development, testing, and use of information systems. The goal of the configuration management process is to establish and maintain the integrity of all identified project deliverables or the process of ensuring access to them by any interested party. The tasks of managing the configuration of the project are:

1. Defining a configuration management strategy that includes the following items:

o - determination of the authority to prohibit or allow access, the implementation and control of changes to configuration elements;

o determining the location and storage conditions of configuration items, including environmental requirements, and in the case of information, storage requirements for information carriers in accordance with the assigned levels of integrity, security and safety;

o determination of criteria or events corresponding to the start of configuration control and maintenance of baselines in the process of evolution of configurations;

o defining the audit strategy and responsibility for ensuring the continuous integrity and security of information describing the configuration;

2. identification of elements that need to be controlled in the configuration management process;

3. Maintain configuration information at an acceptable level of integrity and security. For this it is recommended:

o maintain configuration records throughout the life cycle and archive them in accordance with agreements, legislation or industry best practices;

o Describe the configuration in accordance with industry or technology standards, where applicable.

o register the rationale for changes to the baseline configuration and related permissions data;

4. ensuring that configuration baseline changes are appropriately identified, recorded, evaluated, approved, conducted, and verified. For this it is recommended:

o register configuration steps;

o manage the execution of records, changes and statements of the current configuration status and the status of all previous configurations to confirm the correctness, timeliness, integrity and security of information;

o conduct an audit to verify the compliance of the base line of the Criminal Code with the requirements for the project results

1. Identification of configuration management objects.

2. Infrastructure planning under development.

3. Establishing the project configuration baseline.

4. Assessment of compliance with the baseline configuration.

5. Control configuration of selected project elements.

6. Ensuring the integrity of configuration items.

7. Project infrastructure reconfiguration

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

Description of the reason:

Actions

Base

Modified

Characteristics of the modified stage / process

Stage

Process

Stage

Process

Purpose

purpose

Result

_

_

Application date (project manager):

Date of decision (project office):

Starting date:

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

ХАРАКТЕР ВОЗДЕЙСТВИЯ НА БИЗНЕС

Создание новых возможностей

Повышение эффективности операций

Отказ от операций

СТЕПЕНЬ ОПРЕДЕЛЕННОСТИ

Финансовые

Quantitative

Измеримые

Qualitative

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

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 .


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