Lecture
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 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:
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.
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:
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.
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.
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:
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.
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:
2. Contents of the test script:
3. Footer:
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:
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.
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:
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:
Testing of reports and documents generated by the system should be provided in the testing cycle - the implementation of such scenarios will ensure:
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:
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.
Помимо проектной документации, в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:
Акт сдачи-приемки услуг к договору на консультационные услуги, составленный в двух экземплярах (по одному для каждой из сторон), подписывается спонсором со стороны исполнителя и спонсором со стороны заказчика.
Утверждение спонсором со стороны заказчика отчетных материалов, определенных согласно плану по фазам проекта, устанавливает факт оказания услуги по договору и подтверждается подписанием акта приемки-сдачи работ в соответствии с договором.
После оформления акта о выполненных работах исполнитель оформляет печатный экземпляр материалов, передает заказчику и закрывает проект.
Пример процедуры управления открытыми вопросами
Открытые вопросы - это вопросы, которые возникают в ходе работ проектной команды и по той или иной причине не могут быть решены в момент возникновения, мешают завершению проектного задания и, таким образом, могут вызвать задержку получения проектных результатов и нарушить утвержденный план-график работ по проекту.
Управление открытыми вопросами и проблемами осуществляется на двух уровнях
Уровень функциональной группы: список открытых вопросов/проблем функциональной группы (ответственный за управление этим листом - руководитель функциональной группы, описание управления этим листом не является задачей описанной ниже процедуры). Руководитель функциональной группы является инициатором открытых вопросов/проблем, которые не могут быть решены в рамках его компетенции, и направляет их администратору проекта, который вносит их в общий реестр.
Уровень проекта в целом: список открытых вопросов/проблем на уровне проекта в целом (ответственность руководителей проекта).
Порядок работы с открытыми вопросами и проблемами уровня проекта в целом
Открытый вопрос/проблема могут быть сформулированы любым участником проекта на своем уровне.
Если открытый вопрос/проблема требуют интеграции между участниками одного рабочего направления (например "Финансы" и "Сбыт и логистика"), то они должны организовать совместную встречу, в случае необходимости - с участием группы интеграции/архитекторов проекта, и попытаться прийти к решению.
В случае если открытый вопрос/проблема не могут быть решены на уровне функциональной группы или рабочего направления, они по электронной почте в содержании письма направляются на рассмотрение администратору проекта и должны быть освещены на еженедельной статус-встрече.
Администратор проекта консолидирует и ведет (собирает дополнительную информацию по вопросу, напоминает о сроках, отведенных на решение вопроса и т.д.) единый журнал проблем проекта, также отвечает за коммуникацию проблемы доведение проблемы до сведения руководителей проекта с обеих сторон и следит, чтобы они вовремя предоставили информацию об ответственных и сроках решения.
Руководители проекта с обеих сторон на еженедельной основе рассматривают и принимают решения по открытым вопросам/проблемам, а также назначают ответственного за решение проблемы; время на решение проблемы устанавливается в зависимости от сложности вопроса/проблемы, но не более 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
software project management
Terms: software project management