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

18. Project management in the development and implementation phase

Lecture




18.1. Detailed planning of the development and implementation stage

The tasks of planning at the stage of development and implementation coincide with the tasks of the previous stage. An additional task is to train staff to complete the project. The solution to this problem includes the following actions:

  • notification of project management, customer and staff;
  • preparing staff performance assessment;
  • documenting the results of the personnel management process.

Notification of the customer’s project management and staff implies informing project managers of plans to release their personnel, checking contractual compliance, and discussing plans for release with project personnel.

For performance assessment of personnel use the methods and procedures adopted by the company. An example of a personnel assessment methodology was proposed by V.Ilinin and presented in the book "Management of Project Quality. Practical Experience" [13].

All accumulated knowledge acquired during the project must be documented and may include:

  • project organization charts, position descriptions, and staffing management plans for the project;
  • principles, methods of conflict resolution and incentive procedures;
  • special skills and qualifications of certain team members, discovered during the execution of the project;
  • Problems and methods of their solution, recorded in the logbook of project problems.

18.2. Infrastructure preparation for the operational phase

During the development and implementation phase, the project results are verified to be in compliance with the project requirements and the configuration management process is completed. The result of this phase is to ensure the readiness of configuration management by the customer.

To verify compliance, an audit of key results is performed.

As part of the audit of key results, the configuration manager demonstrates to the project manager and the customer that the obtained and planned results are consistent and that there is adequate control over the results. The results of this subprocess are further used by the project manager when the customer signs the act of accepting key project results.

The configuration manager prepares and negotiates the audit requirements and key project results and ensures that the audit is conducted. The project administrator provides the preparation of status reports for the configuration required for the audit.

Completion of the configuration management process is the transfer of responsibility for the project configuration process to the customer, as well as the preparation and transfer of an archive with project materials.

The project manager on the client side develops requirements for completing the configuration management process, and it is recommended that this be done at the planning stage. The project manager from the contractor agrees with the customer on the procedure for transferring configuration management tools. The configuration manager archives project configuration information and organizes the archive transfer process.

The transfer of the results of the QM process to the customer must be consistent with the transfer of results related to the development and testing of the information system. For the transfer of archival copies, it is recommended at the planning stage to develop and coordinate with the customer the appropriate procedure.

18.3. Implementation of project quality control totals

At the development and implementation phase, within the framework of the quality management process, work is carried out to check the compliance of the stage results with the established quality criteria and standards.

The tasks of this phase include:

  • evaluation of the organization of quality control of design work;
  • auditing key performance indicators.

A critical success factor at this stage is the exact correspondence of the procedure of acceptance of the stage to the quality plan of the works to the project.

The background information is audit reports and quality review comments.

18.4. Manage customization and deployment risks

The identification of risks at this stage is carried out similarly to the process of identifying risks at the previous stages.

Assessment of the feasibility of risks, monitoring of the status of identified risks occurs similarly to the process at the previous stages.

Updating the risk management log is done similarly to the process in the previous stages.

Risk management at this stage is carried out similarly to the process at the previous stages.

18.5. Staff training for project completion

The methods and tools of personnel management at this phase are similar to those previously discussed, however, one key feature needs to be taken into account - the close completion of the project and the importance of checking staff readiness for this. The solution to this problem includes the following actions:

1. notification of the project management, customer and staff.

Notification of the project management, customer and staff implies informing project managers about plans to release their personnel, verify the fulfillment of contractual obligations, discuss plans for release with project personnel;

2. training staff performance assessment.

For performance assessment of personnel use the methods and procedures adopted by the company;

3. documenting the results of the personnel management process. All accumulated knowledge acquired during the project must be documented and may include:

  • project organization charts, position descriptions, and staffing management plans for the project;
  • principles, methods of conflict resolution and incentive procedures;
  • special skills and qualifications of certain team members, discovered during the execution of the project;
  • Problems and methods of their solution, recorded in the logbook of project problems.

18.6. Testing organization

At this stage, the key process of quality management is testing, but it must be accompanied by a number of preparatory actions, as well as measures to evaluate the quality criteria of the processes planned at the previous stage.

  • Evaluation is carried out according to previously developed procedures, based on checklists to verify project management and reporting.
  • Setting up the working environment.
  • Configuring (for system testing).
  • Infrastructure setup, system testing.
  • Perform a system and user test.
  • Installation of the working environment.
  • Run a run test.

The testing process as such is intended to assess the degree of compliance of the functional characteristics of the implemented solution with the initial requirements and to ensure a smooth transfer of the project results to the operational activities.

The main purpose of testing is to verify that the implemented technologies and organizational support support new ways of working for the company. The key object of the testing process are test scripts, the essence of step-by-step instructions for testers. It is obvious that the full set of project test scenarios should cover as many possible situations as possible (Gal-Lopeen).

According to the recommendations, a typical test scenario has the following structure and content.

1. Header:

  • test script header;
  • description of the test scenario;
  • the purpose of the execution of this test script;
  • affected functional area, process, organizational unit and role;
  • used system transactions;
  • the expected duration of the test scenario and the target duration of the scenario in real conditions.

2. Contents of the test script:

  • step by step instructions for performing operations;
  • the expected result of each operation;
  • tester comments;
  • mark on the successful implementation of the test script.

3. Footer:

  • mark of formal acceptance ("yes" / "no");
  • general comments on the execution of the script.

1. Implementation of the testing cycle

To ensure comprehensive testing of the functioning of the implemented system, it is necessary to implement a testing cycle consisting of the following ordered stages.

2. Functional testing

Performing this type of testing is done immediately after setting up the relevant functionality and ends when each part of the setting functions in accordance with documented requirements.

3. First integration testing

At this stage of testing, the designed prototype of the system is tested for the first time in its entirety. The highest priority is given to the work on the correction of detected errors: some errors can block the passage of the script and identify other errors. At the end of the first integration test, an assessment of the feasibility of a transition to the productive operation of the project results is made.

4. Second Integration Testing

It is executed after the elimination of all previously identified problems and errors. At the end of this phase, it is necessary to check whether end-user acceptance testing has been launched. At the same time, it makes sense to delay acceptance tests, if there is reason to believe that the quality of the system does not meet the originally established requirements. Practice shows that the detection of a larger number of errors during the acceptance test cycles significantly reduces the likelihood of a customer accepting the system [5].

5.First user testing

This stage of the testing cycle is preceded by the elimination of previously identified errors, ensuring user access to the testing environment, explaining all procedures to testers. To ensure prompt problem solving and continuous tracking of testing progress, it is worthwhile to organize this testing in one place. Following the results of this cyclic testing it is necessary:

  • form a final conclusion on the results;
  • document all change requests;
  • make sure all test cases are approved;
  • make a final assessment of the possibility of transition to productive operation.

1. Final system setup

Based on the information obtained following the results of the first acceptance testing, as well as the registered change requests, the system is finalized and the changes are approved. Correct processing of this stage greatly simplifies the acceptance process, as changes were made to the system to ensure greater compliance with the requirements and existing practices.

2. Second User Acceptance Testing This is the final round of testing: all test scenarios that have not yet been passed must be passed and confirmed. Upon successful completion of this cycle, the transition to productive operation must be approved.

Testing of processes, documents and reports

For a number of reasons, process testing should be implemented separately.

  • Ability to check the steps of the process in practice.
  • Evaluation of the impact of the implemented system on the daily work activities of the company's employees.
  • Assessment of readiness of a function-oriented organization to make the transition to process management.
  • Check the integrity and consistency of the developed instructions.
  • Ability to test the new process step by step.

As a template for performing process testing it is recommended to use the form given in table. 18.1.

Table 18.1. Template for documenting the results of process testing

Roles

Process steps

Organizational units

...

...

...

...

...

...

...

...

...

...

...

...

...

.

.

.

The left section of the table, consisting of several columns, describes the roles involved in the testing and the steps of the process that they perform. Accordingly, the following values ​​may be indicated in the cells:

  • applicable (the role takes part in the process);
  • not applicable (the role does not participate in the process).

In the central column, the subprocesses / steps of the process being tested are listed.

The right section describes the test result in the context of the involved organizational (business) units. The cells in this section can have the following values:

  • test script passed;
  • test script passed with a workaround;
  • a defect has been identified;
  • test script is not applicable;
  • The test script is applicable but not verified. The above template allows you to keep under review a picture of the readiness of the process and compare one enterprise with another.

Testing of reports and documents generated by the system should be provided in the testing cycle - the implementation of such scenarios will ensure:

  • high quality of external documents intended for clients and partners of the organization, which has a positive effect on the company's image;
  • a higher likelihood of mid-level management acceptance of the system if they were involved in the design and testing process.

18.7. Transition to productive operation

The date of entry into productive operation must be planned very carefully. The whole organization must be prepared. It is necessary to clearly understand that productive operation means not only the launch of a new information system, but also the abandonment of the old system and some established principles of operation. However, in some companies it has been common practice to use the old systems in parallel for some time - this practice is fraught with big problems, up to rollback of the entire project.

The transition plan to productive operation should contain a detailed description of the transition from the current methods of work [5,9] and the use of the current system to new methods of work in the new organizational and information environment of the enterprise. This plan should be drafted in great detail and contain, among other things, a backup plan or a rollback scenario of the system being implemented to ensure continuous operation.

In addition, at this phase, the project manager should, together with the quality managers, make an assessment and, if necessary, adjust the project quality assurance program for the operation phase, which is fundamentally different from all previous non-project activities.

In order for the quality program to be relevant even at the operational stage, the quality manager must organize and verify the execution of the following actions:

  • checking the availability of quality assurance operations for the following processes:
  • documentation formation;
  • extra education;
  • adjustment of the implementation schedule, the list of those responsible for quality assurance;
  • coordination with the project manager of the adjusted quality assurance program;
  • checking the availability of procedures for documenting and approving the system of delivery and acceptance of the system;
  • improvement of quality assurance and quality control procedures at the operational stage.

18.8. Completion of the project (phase)

Project completion implies completion of all operations of all groups of project management processes (of this stage) in order to formally complete this stage and move on to the next one.

An example of the process of accepting the results of the work of employees of the contractor and members of the project team from the customer

Simultaneously with the process of planning the work of consultants on the part of the executor, work is planned for the participants of the project team from the customer. Work plans for the project team members from the customer are developed by the leaders of the functional groups. The project manager from the contractor summarizes the general work plan of the consultants from the contractor and the customer’s employees for the next week. The general work plan should contain a list of works, a planned timeframe and an output for each item of the plan. Further, the plan is coordinated with the project manager from the customer, changed if necessary, and approved by the project managers from the contractor and the customer within a week.

The results of the work, which are intermediate, are recorded in the form of the project status for the reporting period and are accepted by the project manager from the contractor and the project manager from the customer based on the work plan for the week.

If at the end of the reporting period, the planned work of the project team member was not completed, the project managers from the contractor and the customer carry out a clarification of the reason for the failure of the planned work. If the reason for non-fulfillment of the planned work cannot be resolved promptly (i.e. within 1 day), it is entered as a problem in the problem log by the project administrator and solved in accordance with the procedure for managing open questions. To solve the problem, project managers from the contractor and the customer produce the establishment of a new deadline for the work.

Sample procedure for accepting project results

The procedure for accepting project results is the process by which the results of the project phase are agreed upon and the governing body's decision to move to the next phase, including the process of transferring, agreeing and approving project documents, is formalized and documented.

Помимо проектной документации, в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:

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

(ix) Пример процедуры согласования

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

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

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

Пример процедуры управления открытыми вопросами

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

Управление открытыми вопросами и проблемами осуществляется на двух уровнях

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

Уровень проекта в целом: список открытых вопросов/проблем на уровне проекта в целом (ответственность руководителей проекта).

Порядок работы с открытыми вопросами и проблемами уровня проекта в целом

Открытый вопрос/проблема могут быть сформулированы любым участником проекта на своем уровне.

Если открытый вопрос/проблема требуют интеграции между участниками одного рабочего направления (например "Финансы" и "Сбыт и логистика"), то они должны организовать совместную встречу, в случае необходимости - с участием группы интеграции/архитекторов проекта, и попытаться прийти к решению.

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

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

Руководители проекта с обеих сторон на еженедельной основе рассматривают и принимают решения по открытым вопросам/проблемам, а также назначают ответственного за решение проблемы; время на решение проблемы устанавливается в зависимости от сложности вопроса/проблемы, но не более 5-ти рабочих дней.

If the issue / problem is not resolved within the timeframe set by the project managers, or cannot be resolved at the project manager’s level, or is reflected in the terms, budget, resources, quality of the project, then they are drawn up as one of the agenda items of the project’s governing body and submitted for its consideration at the next meeting; at the same time, the project administrator logs a question / problem in the problem log from an email received from project managers.

В случае решения вопроса/проблемы в управляющем комитете и при отсутствии влияния проблемы на сроки, бюджет, ресурсы, качество проекта указанные вопрос/проблема считаются закрытыми и оформляются администратором проекта в журнале проблем изменением статуса вопроса/проблемы на "закрыто"; в противном случае вопрос/проблема переоформляются в виде запроса на изменение.

Журнал открытых вопросов ведется только администратором проекта и доступен для чтения всем участникам проекта.


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