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

15. Managing participants of an IT project at the design stage

Lecture




15.1. Implementing integrated change management

Implementation of integrated change management is performed from the beginning of the project until its completion. Change management is necessary because projects are a unique enterprise and are rarely carried out strictly in accordance with the management plan.

A project management plan, a description of project content, and other deliverables must be maintained through the organization of continuous integrated change management. Thus, the process of implementing integrated change management is the process of analyzing all requests for changes, approving them and managing changes to results, procedures and policies and project documents.

The correct implementation of this process allows the project team to take control of the reasonable changes to the project. This update information is used, among other things, to keep track of the progress of the project and to close it upon completion.

The main tool for translating conversations about integrated change management to the level of specific actions, procedures and responsible roles is the Change Coordination Matrix (CCM) and its associated change request (Project Change Request - PCR) and project change log (ProjectChange). Log - PCL). The integrated use of these tools introduces order and the process of making changes to the project: standardized sequence of actions, tasks and formalized roles significantly reduce problems such as the spread of project content (scope creep), budget overruns and shifting the project completion date.

Change Coordination Matrix [18]

In accordance with the recommendations, the change coordination matrix consists of the following elements (see Figure 15.1).

  15. Managing participants of an IT project at the design stage


Fig. 15.1. Example Change Coordination Matrix (CMS)

1. Forming a change request

Any member of the project team, or even a project member who is inside the organization, may submit a PCR on the assumption that the content of the project has not yet been frozen. The template and PCR filling principles are discussed in this section below.

2. Registration of a request for changes in the project change log

The project may provide for the role of change coordinator, or this function is part of the job responsibilities of the project manager. After receiving the PCR , the change coordinator registers it with the PCL and sends it to all interested parties and to the project management body that approves or rejects the changes.

3. Consideration of the request for a change to the draft Expertise of the project’s steering committee and, possibly, the results of additional analysis made by other interested parties, are the basis for making a decision either on the approval or rejection of the proposed change.

4. Decision making on a change request to a project Often, in order to prevent redundant changes from being initiated by the change initiator, it is required to indicate the type of change he suggests in terms of "necessary" or "desired" ("must have" and "nice to have" ). A “necessary” change is one without which the project can become a failure, therefore, such a change requires proper attention and approval. On the other hand, the “desired” change usually gives the product additional functionality, but does not change its essence. At the same time, the desired change can easily lead to additional rescheduling efforts, which becomes the main reason for rejecting such a change. The necessary / desired change approach can be a good way to avoid the risks of substantial content creep.

So, the decision made on request is fixed in PCL . When a change request is rejected, a copy is placed in the main file, and the original is returned to the author with an explanation of the decision and the reasons for it. If the PCR is approved, the coordinator gives it official status and sends it to those affected by the change for implementation. The coordinator also informs the author.

Quite often, there is a situation where the change authority finds the PCR incomplete and encourages the coordinator to request more information from the author.

5. Monitoring the implementation of changes

The life cycle of a PCR does not end when it is approved. With the help of PCL, the coordinator needs to continuously monitor the state in which the practical implementation of the change is located.

6. Updating information about the timing, cost, quality, etc. of the project

The approved changes may change the basic parameters of the project - the total cost and the completion date, therefore, this information should be updated in the relevant documents, which again should be reflected in the PCL .

Request for Changes

Obviously, the changes made to the project have an integrated effect on it: this is the content, the schedule, the cost, the quality, and other parameters - which is very difficult to control without the presence of appropriate standardized procedures. It is very important to ensure that each change is comprehensively analyzed before permission is granted for its practical implementation. The change coordination matrix decides the procedural part, while the substantive part is described using a change request, which allows you to evaluate the overall impact on the project of the proposed changes (see Table 15.1).

Table 15.1. Change Request Template ( PCR )

Project name

_____________________

Request No.

_____________

Description of the proposed change and its impact on the content and quality of the project

.

Request author

date of application

Reason for request

Emergency measures (if any)

Change Detection Cost

Change type

Significant (re-planning required)

Insignificant

Change Detection Cost

Description of the impact on the project schedule

.

Estimation of terms made according to the document.

Description of the impact on the cost of the project

.

The cost estimate is made according to the document.

Is the change funded by the customer?

If yes, indicate the basis document.

Management Committee Resolution

.

Date of decision

On the template you can see that the request is a form with a recommended volume of no more than 1 page, its preparation may take some time and require the participation of various specialists.

If possible, it is recommended to implement changes in the early stages of the project, at a time when the cost of their implementation is traditionally much lower. Over time, moving ahead with the project schedule increases the cost of making changes [11]. Generally speaking, at the planning stage, it usually does not make sense to use PCR : if there is only roughly defined content, there is no practical need to try to control the changes using a formalized procedure. However, at a later stage of design, PCR acquires practical meaning and its use becomes financially viable. For example, on a new product development project, it makes sense to use PCR for changes that deviate from agreed technical specifications and affect specifications issued by the engineering department for procurement or production planning. However, at some point in time, making changes to a project can slow down the progress of a project, potentially leading to costly rework. In such a situation, an effective step is to freeze the project on the substantive part, after which no changes will be considered, unless there are critical reasons in favor of such a review. An example is a customer-sponsored requirement to add a new safety indicator to a product.

Recommendations for completing the content sections of the PCR (see table. 15.1)

1. Description of proposed changes and their impact on the content / quality

The description of the requested change must be sufficiently accurate to give a proper understanding of which part, subject of delivery or work package should be changed and how. The need for long descriptions is eliminated; the language used for this purpose should be as concise as possible.

2. Explanation of the reasons for the change

Motivation may be different. In order to have confidence in the correct understanding of motivation and to avoid motivation that is harmful, it is recommended to apply the "necessary / desired change" approach described above. This technique may seem unnecessarily simple, but it allows the project manager to protect himself and make sure that each proposed change has its own rationale.

3. Identification of the need for urgent change measures A typical problem that sometimes accompanies an overly formalized process of integrated change management is

that consideration is excessively slow. To overcome this problem, the “emergency measures” column is introduced, the task of such a PCR is to inform the change authority that the requested change needs urgent consideration and approval. This may mean that the change body will have to act quickly. It is extremely important that emergency changes are not a justification for misleading assessments in terms of quality, performance, reliability, safety, or any other aspects.

4. Evaluation of the impact on the project schedule

A network diagram showing the logical dependencies of operations helps to analyze how changes in one delivery item and its corresponding operations will affect dependent operations that are located further in time. Often, the assessment of the impact on the schedule is performed intuitively, which is on average 40% less effective analytical approach (McAfee, 2009), while an informal, but well-executed analysis of the network schedule will benefit any project.

5. Evaluation of the impact on the cost of the project

Requiring valuation of the value or resources required for a proposed change is an effective strategy for preventing financial surprises. The requirement to perform a database-based bottom-up assessment when submitting a change request is a well-founded precautionary measure aimed at countering the inherent tendency of people to lower cost estimates. If the change is significant, it is entirely possible to go further and request an estimate from an independent source in order to compare it with the estimate of the author of the change.

6. Identify type of change

To avoid the risk of “spreading out” the project schedule, volume and budget, it is necessary to sift through all the proposed changes by determining how they will affect the content and quality of the project. If the change has little impact, then it can be considered as a minor corrective impact, without affecting the basic content, quality, cost, and schedule plans. Conversely, a change can be defined as a significant change in the content of work, financing and timing. This can justify the need for re-planning (or redefining the base plan), including changes to schedules, budgets and resource allocations. In order to make everyone involved fully aware of such consequences, it is necessary to determine whether this change is significant or insignificant. And this, in turn, becomes possible only after evaluating the impact of changes on the content, quality, cost and schedule.

7. Decision Making / Resolution on PCR

Approval of a change request - initiation of actions to implement the change. Like any project work, this action requires planning, highly scrupulous for large projects and less scrupulous for small projects. Planning for change action and careful monitoring of its implementation are prerequisites for its successful completion.

Project Change Log

A change request allows you to collect detailed information about a specific change, but for the purposes of coordinating the flow of changes that accompany any project, it is common to use a change log (see table 10.2). Administered by the change coordinator, PCL records every request for a change to the project and assigns a number to it, ensuring that the decision taken on the request, whether it was approved or rejected by the project management committee, is also recorded.

The role of PCL as a repository of changes provides good control over all requested, rejected, approved, executed and completed changes. The value of this information lies in its potential ability to prevent loss of funds and delays in the project by informing decision makers about the impact of major changes on the budget and schedule of the project. Such clarity inevitably reduces confusion often encountered in situations where PCL is absent.

Table 15.2. Project Change Log Template (PCL)

Project name

Sheet number

__ of __

The number of the request for a change to the project

Request author

A brief description of the proposed change.

date of application

Ok?

Date of issue

Completed?

Evaluation of the impact on the cost and terms

Updated project cost and completion date

.

.

The change coordination matrix provides a sequence of steps through which the change takes place, and thus describes the procedure for reflecting information in the PCL. The change request is subject to PCL administration — the relevant information from the PCR is reflected in the project change log. It is extremely important to track the status of each change request, for this the following information can be displayed in the "Completed" column: "Not yet" or "Yes".

15.2. Project quality assurance at the design stage

Work on ensuring the quality of the project in the design phase is aimed at solving the following tasks.

  • Making adjustments to the basic quality management plan, which would reflect the changes agreed upon by the contractor and the customer at the previous stage.
  • The initial information for the preparation and modification of a quality management plan are the strategies, standards and procedures of the quality management process. The main objective of the stage is to clarify strategies, standards and procedures so that they correspond to the tasks of the second phase.
  • Another task of the stage is to ensure that a plan for conducting an audit and quality reviews is prepared at the planning stage begins with the identification of key results and milestones at this stage. For each key result, a quality review is planned. Additional quality reviews are carried out before the checkpoints related to the acceptance by the customer of the project results, which will allow identifying problems in advance of the acceptance procedure by the customer and deciding on their elimination. The project schedule is adjusted to the quality audit. The set of procedures necessary to ensure quality management work at this stage should be checked [22].

At the planning stage of the life cycle design phase of IT, the project manager together with the quality manager performs the adjustment of the project quality assurance program.

To do this, pre-quality manager carried out:

  • checking the availability of quality assurance operations for the following processes:
  • working environment setting;
  • configuration configuration (for system testing);
  • infrastructure setup, system testing;
  • performing a system and user test;
  • installation of the working environment;
  • run a run test;
  • preparation and conduct of training for end users;
  • adjustment of the implementation schedule, the list of those responsible for quality assurance;
  • coordination with the project manager of the revised quality assurance program, which also includes a description of the quality assurance of the following processes:
  • creating design specifications;
  • creation of technical specifications;
  • definition of integration methods and modifications;
  • determination of testing criteria;
  • identification of additional training requirements;
  • configuration setting;
  • installation development environment;
  • installation of the test environment;
  • development of functional characteristics;
  • testing parameters / functions;
  • process testing;
  • general testing;
  • creation of technical and user documentation;
  • checking the availability of necessary procedures;
  • finalization of quality assurance and quality control procedures at the production stage (setup and implementation).

15.3. Ensuring the integrity of configuration items

During the design phase, project configuration management actions are used to ensure the integrity of the baseline results of the current and previous phases of the life cycle of the IS.

The task of ensuring the integrity of the configuration in this phase includes, on the basis of strategies, standards and procedures of the Criminal Code, ensuring maintenance and control of documents, management of delivery results and accounting for the state of the configuration, protection of the product or service being created.

The maintenance and control of documents implemented at this stage, as before, provides for the preservation and maintenance of project documentation. The purpose of the subprocess is to ensure:

  • доступ к документам для ознакомления;
  • защиту документов от несанкционированного доступа;
  • контроль за ведением документов;
  • осведомленность получателя о статусе документа;
  • обеспечение процедуры обзора и утверждения документа.

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

Производимый на данной фазе контроль конфигурации предназначен для управления элементами конфигурации [22]. В рамках данного процесса должна быть обеспечена возможность модификации элементов конфигурации. Например, новые результаты по проекту, как правило, означают создание нового элемента конфигурации. Данный подпроцесс должен обеспечиватьзамораживание состояния элементов конфигурации, например, при достижении базового набора конфигурации. Менеджер по управлению конфигурацией осуществляет контроль конфигурации, а руководители проекта со стороны заказчика и исполнителя принимают участие в принятии решений по вопросам, возникающим в процессе контроля конфигурации.

Управление результатами поставки, в свою очередь, обеспечивает подготовку и доставку результатов по определенным адресам. Если рассылка производится часто и по многим адресатам, рекомендуется процесс рассылки автоматизировать.

Создание и выполнение процедур подготовки результатов поставки, а также определение содержания результатов поставки и подготовка справок о выпуске выполняет менеджер по управлению конфигурацией. Менеджер проекта принимает решения по доставке результатов заказчику. В обязанности менеджера проекта со стороны заказчика входит подтверждение получения релизов заказчиком.

Учет состояния конфигурации производится с целью отслеживания состояния конфигурации и ее элементов. В задачи подпроцесса входит предоставление из репозитория УК следующей актуальной информации о состоянии всех элементов конфигурации:

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

Менеджер по управлению конфигурацией совместно с руководителем проекта выполняет анализ информации, подготовленной для издания бюллетеней о состоянии элементов конфигурации. Администратор проекта готовит и выполняет рассылку бюллетеней о состоянии конфигурации менеджерам по управлению проектом со стороны заказчика и исполнителя.

Оценка соответствия базовой линии конфигурации

Для обеспечения контроля конфигурации по проекту рекомендуется разработка и использование следующих процедур:

  • добавление/удаление элементов конфигурации;
  • задание базового набора;
  • "замораживание" версий.

At the stage of completion of the stage, the main results are audited. A memorandum on the end of the stage, containing the key results of the stage, is provided to the customer in the form agreed by both parties.

15.4. Updating the risk register in the design phase

The following sources of risks are most typical for the design phase of life cycle ICs [17]:

  • the scope of the project is adjusted without appropriate change management;
  • the time and resources allocated are not sufficient to provide the stage with personnel with the necessary qualifications and number and personnel training;
  • the implementation of the project schedule requires personnel resources not previously planned;
  • project risk assessment is not adjusted;
  • procedures for accepting project results are not agreed with the customer.

Наиболее распространенными действиями, направленными на смягчение вышеперечисленных рисков, являются действия, направленные на то, чтобы:

  • результаты предыдущего этапа регулярно документировать, обеспечивая утверждение запросов на изменение;
  • на предыдущем этапе устанавливать состав критичного для данного этапа персонала;
  • составлять и утверждать поименный список участников следующего этапа, выполняя при этом анализ доступности каждого сотрудника;
  • заранее планировать и своевременно проводить тестирование нового ПО;
  • проверять наличие необходимых для следующей стадии элементов конфигурации ИС;
  • выполнить оценку рисков и внести в рабочий и финансовый план меры по сдерживанию рисков.

Для идентификации рисков очередной стадии может быть применена модель управления рисками, основанная на анализе взаимосвязей процессов.

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

При выявлении и анализе рисков существенную помощь могут оказать формализованные методы. Например, в стандарте SPICEописаны 35 основных процессов, используемых при разработке ИС, и методы их оценки, а также приводятся пять групп процессов (взаимодействие поставщика и потребителя, проектирование, обеспечение, управление и организационные процессы) и набор соответствующих базовых методов. При сравнении текущих процессов проекта с приведенными референтными моделями можно выявить вероятные риски каждого из процессов [15].

15.5. Набор команды проекта

The main tasks of personnel management at the stage of life cycle design are:

  • making adjustments to the personnel management plan to reflect the agreed changes of the previous stage;
  • drawing up a detailed work plan for personnel management for the implementation of work at the design stage;
  • receiving confirmation from the customer about the allocation of the required resources and the implementation of resource commitments made;
  • identifying changes in the project infrastructure that need to be made to support project implementation;
  • project team development.

The baseline information for accomplishing the above tasks is the basic personnel management plan, strategies, standards and procedures for the resource management process.

В ходе процесса управления ресурсами на стадии проектирования основное внимание уделяется планированию и распределению персонала с требуемой квалификацией для выполнения запланированных работ этапа. Основные методы решения этой задачи - организационное планирование, оценка навыков, набор персонала, ведение переговоров. В процессе планирования этапа участвуют менеджеры проекта со стороны исполнителя и заказчика, поскольку со стороны заказчика нужно согласовать позиции, которые занимает персонал, и определить его ответственность. Поскольку во время выполнения проекта происходят организационные и временные изменения, подбор, организация и обучение команды становятся одной из самых значительных проблем проекта. Чтобы обеспечить проектные работы человеческими ресурсами в нужное время и с требуемой квалификацией, организуют обучение персонала. Планы обучения составляются таким образом, чтобы обеспечить в полной мере исполнениечленами команды своих ролей. Для крупных проектов обучение необходимо внести в рабочий план, чтобы учесть загруженность персонала и возможности его привлечения к работе над проектом [18]. Обучение могут производить как организация-исполнитель, так и специализированные учебные центры. При разработке плана обучения должна быть разработана процедура контроля качества произведенного обучения, которая включает действия по проверке знаний на предмет их соответствия требованиям к квалификации планируемых работ.

Описание процесса

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

Согласно PMBOK [1,23], набор команды проекта - это процесс привлечения человеческих ресурсов, необходимых для выполнения проекта.

При наборе членов команды проекта необходимо учитывать следующее:

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

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

Ключевой информацией при наборе команды являются: схема распределения ролей и ответственности, необходимые навыки и квалификация, разработанные на этапе планирования команды проекта.

Исходной информацией для определения численности команды проекта являются расписание проекта и организационные диаграммы. Пример шаблона организационной диаграммы приведен на рис. 15.2. Организационная диаграмма проекта - это графическое представление состава команды проекта и отношения подотчетности между ее членами. В зависимости от потребностей проекта она может быть официальной или неофициальной, подробной или обобщенной [18].

  15. Managing participants of an IT project at the design stage

Fig. 15.2. Шаблон организационной диаграммы [18]

План управления обеспечением проекта персоналом и расписание проекта определяет сроки, на которые привлекается каждый член команды проекта, и время его высвобождения.

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

When selecting a project team, various psychological tests are of interest, helping project managers to include in a team people whose personal characteristics cover a range of qualities necessary for successful project implementation. An example is the test of Meredith Belbin, an American psychologist who has devoted more than ten years to studying the conditions necessary for successful operation of management teams. Belbin suggested that each team member plays two roles: functional, related to the formal specifics of the activity, and the “team” role, especially important for the successful operation of the team. Belbin identified and described eight types of team roles that characterize the entire role diversity of a team: "performer", "chairman", "shaper", "thinker", "resource explorer", "evaluator", "collectivist" and "follow through" . The main quality of the "performers" is discipline, organization, conscientiousness, commitment to commitments, a serious attitude to any business, reliability, practicality, tolerance for others. "Artists" - effective organizers and administrators. They have a practical and realistic approach to doing work. For the "collectivist" is characterized by a consultative leadership style and a tendency to informal communication with colleagues and subordinates. They make excellent tutors of young managers. The main purpose of the “thinker” in a team is to introduce new and original ideas. A “chairperson” is a person who knows how to use resources, is extremely adaptive in communicating with people, but at the same time never losing control of the situation and the ability to make independent decisions. Belbin's testing allows you to determine the team role of a potential team member and, when forming a team, include people with personal characteristics, d ±, so that all eight roles are implemented in the team. Full role-playing structure creates the prerequisites for effective partnerships. If the project team works inefficiently, it is useful to analyze its composition in the light of the eight roles considered.

  15. Managing participants of an IT project at the design stage


Fig. 15.3. Template for documenting the recruitment process

The team recruitment process ends with staffing, documented, for example, in the following video form. 15.3).

For managing the project team and its development, interpersonal skills are important, such as the ability to empathize, influence, and a creative approach to work. By adjusting the mood within the team, creating an atmosphere of respect and trust, the project manager and the project management team can reduce the number of problems that arise and increase the interaction of employees.

In order for the team to be a single whole, measures are being taken to strengthen it. Strengthening team operations can be performed in the form of special trainings. Strengthening the team contributes to the holding of regular discussions on the project, working together on planned tasks, holding informal joint events.

Project teams are encouraged to follow formal principles that make it possible to make team members' expectations understandable and reduce the likelihood of conflicts within the team. With the help of the principles set the rules of conduct for members of the project team. Principles may concern such points as free work schedule, voluntary or compulsory work overtime, training, business trips, bonuses. Compliance with the rules of conduct contributes to increased productivity.

Team cohesion is facilitated by placing project team members in one place. The co-location strategy implies the availability of a room equipped with electronic means of communication, scheduling boards and other devices that facilitate mutual communication.

Encouraging and encouraging the desired behavior of team members is part of the team development process. The promotion plan is created during the planning process of the project team. Decisions on bonuses are made based on the results of the team performance evaluation.

Infrastructure planning for the project team

At the planning stage, the infrastructure is determined and the responsibility for providing the project team with equipment, creating the working environment, and the project library are assigned. Work on the creation of project infrastructure must be monitored.

For the members of the project team at the customer's site, there should be prepared workplaces equipped with office equipment, telephones, personal computers, printers, meeting rooms, training rooms and other material resources.


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