Lecture
The process of developing a project management plan is the process of documenting the actions necessary to define, prepare, integrate, and coordinate all supporting plans. A well-designed project management plan is the main source of information about how the project will be planned, evaluated, monitored and closed. The project management plan is updated and edited as part of the implementation of the project’s integrated change management (see the relevant section). To support versioning of the document, it is recommended to use the document management sheet, the template of which is presented in Table. 5.1.
A project management plan can be either summarized or detailed and consist of one or more supporting plans and other elements.
The project management plan is recommended to be divided into 3 blocks according to the nature of the information contained in them.
1. Auxiliary project management plans, which include:
2. The basic line of the project, consisting of:
3. The results of the analysis carried out by the project team in relation to the content, scope and timing of the project.
Consideration of the main supporting management plans and elements of the baseline of the project, as well as a description of the key methods and procedures for the preparation of these plans, are devoted to separate sections of this book.
The work hierarchy (WBS) is a results-oriented way to group project elements, which organizes and defines the overall content of the project. Works that are not included in the SRI are outside the scope of the project [18].
The model can be executed graphically, in the form of a tree structure or in the form of a verbal description. With its help, the entire content of the project is structured and determined.
Building an IMR
There are two main ways to develop an SRI: “top down” and “bottom up”. The following is a description of the top-down approach.
1. Collect baseline information.
Developing an WBS will be easier and more meaningful if the following information is available:
2. The choice of type of SRI
After obtaining the necessary information about the factors influencing the structure of the SRI, it is necessary to determine the type of construction of the SRI: by life cycle, by systems, by geographic zones.
In accordance with the principle underlying the construction of the SRI in the phases of the life cycle, at the first level the project is divided into phases. This principle of following the natural life cycle of a project is very popular in some industries and, in principle, greatly simplifies the development of a project schedule. A good example of the use of this type of structuring of ISR is a software development project consisting of such phases as requirements definition, high-level design, low-level design, code writing, and testing. The principle of breaking by systems implies breaking up the constituent physical systems and displaying them at level 1 of the SRI. This approach is widespread in a number of traditional manufacturing industries in which the WBS is more like a production specification. Splitting the SRI into geographic zones is practiced, in particular, in the construction industry, where level 1 of the SRI project may consist of building A, building B, etc. As regards the next levels of SRI, many experts practice hybrid SRIs that combine two or three methods.
When choosing a method of structuring the SRI, it is recommended to follow the standard adopted at the enterprise or in the industry, this will avoid the resistance to the new method that will inevitably arise.
3. Determination of the level of detail of the SRI
Taking into account the fact that the number of packages affects the time and cost of project management, you need to select the number of work packages for which you have time and budget. Generally speaking, the package of work, we will call the main element of the management of the SRI, a discrete problem that has definable end results, for the achievement of which the organizational units are responsible. Obviously, work packages must present small results and be manageable.
The following information is needed to determine the level of detail of the SRI:
An ISR with the following details:
Despite the uniqueness of each project, the previous SRI project can often serve as a template for a new one. For example, most IP implementation projects in a particular organization will have the same life cycles, and therefore the same or similar results from each phase. The WBS template is a tree-like work structure, detailed to the level of work packages, which can be adapted for specific projects in a specific area of the application.
Description of the content of the project is the wording of the project - what needs to be done. The process of developing a preliminary description of a project’s content describes and documents the characteristics and boundaries of the project and its associated products and services, as well as acceptance methods and content management.
The description of the content should allow to evaluate the desired result and serve as a basis for drawing up a basic content plan to be followed in the execution of all project works. In a sense, the description of the content of the project can be compared with the project boundaries - he says that going beyond the boundaries is not allowed without the approval of the manager and that everything within these boundaries is a solution space in which the project team is allowed to act.
The author of this document is the project manager appointed by the project charter, therefore, this document is written from the position of the project executive.
Information that is key to developing a description of a project’s content includes:
In tab. 5.1 shows the requirements for the description of the content of the project: lists the required sections with the necessary recommendations and explanations for their content. Similar to the project charter, it is recommended to use the document management sheet, the template of which was given in the section on the project charter, to maintain the versionality of the document being developed and to track its status.
Table 5.1. Requirements for the description of the content of the project
No | Section | Explanations |
1 . | Project name | Each project should have a name reflecting its essence and at the same time bright enough to attract attention. Approved before the signing of the project charter, the name does not change throughout the life cycle of the entire project |
2 | Project goals and objectives | The purpose of the project is formulated on the basis of the customer’s requirements and the business cause of the project specified in the bylaws, and it does not repeat the wording of the business goal reflected in the charter, but answers the question HOW this business goal will be achieved. The goal of the project should be a statement of the essence of the project and answer the question: "What is the unique value of the project for the client and for the company's business?" In turn, the objectives of the project are the actions to achieve the objectives of the project, performed within the project. Thus, the objectives of the project are the requirements for the project, formed and adjusted using the formal procedure of building a "house of quality" (see the relevant section) |
3 | Requirements for the project decision and project results | It is an element of the basic content of the project included in the project management plan. Description of the characteristics of the implemented project decision and the main results of the project. To ensure communication between customer requirements and project results, it is recommended to use the quality function, more precisely, its second iteration (see the relevant section). Performing the work outlined in the description of the content should lead to the main results. Results may include both intermediate, for example, products of the initial stages of the project (description of the information system architecture), and final ones (launch of the information system into productive operation and provision of support). The results of the project can be both products and services. Information on quantity and quality in generalized form should also be presented in the project description. |
4 | Project boundaries | It is an element of the basic content of the project included in the project management plan. The boundaries of the project determine in general what is included in the project in order to eliminate the situation when a project participant mistakenly considers some product, service or result as part of the project. A comprehensive project review implies explicitly reflecting the functional, organizational, technological, and geographic boundaries of the project. The functional boundaries of the project: business areas, business processes covered by the automation project. With the modular architecture of the system being introduced, this clause defines the functional modules of ERP systems. Project organizational boundaries: it is determined which divisions (including legal entities) should participate in the project - who will use and support IP, on whom depends the development of basic decisions on IP requirements. The organizational boundaries determine the maximum boundaries of the survey and the area of generation of requirements for the implemented IP. Technological: enumeration of all systems and existing interfaces that are associated with the implementation of the considered IT project or will be affected by it, with an indication of the processes supported by each of the systems, and the criticality of each of the systems for business. Geographical: territorial distribution of the project: geographically distant objects to be automated within the project are indicated |
5 | Method of implementation of the project | The project implementation method enumerates the tools, technologies and approaches that will be used to manage the project and achieve its goal. These elements include:
|
6 | The initial hierarchical structure of work ( SRI ) to work packages | It is an element of the basic content of the project included in the project management plan. The hierarchical structure of the project works is a model that reveals the project level by level to the degree of detail that is necessary for effective project planning and control. The model can be executed graphically, in the form of a tree structure or in the form of a verbal description. With its help, the entire content of the project is structured and determined. Information about the work, as a rule, is available in the description of the methodology used (see the section on the formation of the SRI ) |
7 | Resource requirements, staffing and organizational structure of the project (labor intensity, project roles, without specifying specific employees, accountability structure and project management) | The need for resources is determined by the laboriousness of the work reflected in the previously developed SRI . In determining the complexity of work an important source of information is the methodology used for project management (implementation of IP). The organizational structure of the project is also largely determined by the methodology and, moreover, by the culture and internal policies of the client company. In addition, at this stage it is recommended to develop a responsibility matrix (RACI-matrix), allowing to distribute the complex responsibility for the project tasks (see the relevant section) |
8 | Integrated schedule | The enlarged schedule is developed on the basis of control events , information from the project charter and the SRI (level 1 work), in addition, the project management methodology used is an important source of information |
9 | Critical success factors | The conditions on which the project can be the key to success. For example:
Below, see the model of critical success factors distributed by the life cycle stages of an IP implementation project. |
10 | Project Assumptions (by the Executive) | A set of conditions that must be met along with the creation of a project product to achieve a project result. Assumptions cause project risks; during the project they are monitored. Example of assumptions:
Please note that when forming a description of the content of the draft, assumptions are formulated by the implementing organization about the contracting authority |
11 | Project restrictions (by the executor) | The restriction indicates a condition that cannot be violated in the process of creating a project product, or a condition that under no circumstances should the project product satisfy. Restrictions also indicate the ability of the project team to select options for performing any design work [11]. Example of project limitations: making changes to the content of the project is made ... Please note that when drafting a description of the content of a project, restrictions are formulated by the implementing organization on the contracting authority. |
12 | Link to other current programs and projects | Any possible interaction with other projects should be reflected in the description of the project content. It is not enough just to state this connection, it is necessary to indicate where and how the projects relate to each other, and also describe in detail which resources fall under sharing and in which functional areas of the organization and when several projects can be worked on at once. |
13 | Initially formulated risks | At this stage, as a rule, already known risks and main categories of potential risks (for example, external, organizational, procedural, technical, legal, reputational, etc.) are indicated. See related section |
14 | Cost estimate with order of magnitude | Estimates are a representation of project costs for a project by category; for an example, see the template in the appropriate section. To determine the number of attracted resources, use the information from the completed file. |
15 | Project Configuration Management Requirements | Identifies the project's configuration management objects, including project documentation, internal policies, and the product being produced. See the relevant section. |
16 | Acceptance criteria for project results | They are an element of the basic content of the project included in the project management plan. They are a set of standards or rules that define a task with an acceptable level of quality. The acceptance of the product itself is carried out in accordance with the procedure for accepting the results of the project discussed earlier (see the relevant section) |
Critical success factors
The project, being an initiative with very limited resources, is always aimed at their optimal use. For this reason, it makes sense in implementation to pay attention to ensuring one or another critical success factor only at the moment when it is really important for the project, and to reduce the intensity of resource mobilization at other points in time when these resources can be used to provide solutions to other tasks. . In fig. 5.1 reflects a model that describes the significance of each of the critical success factors at different stages of the life cycle of an integrated circuit. The indicated points reflect the estimates of the significance of critical factors normalized on a ten-point scale at the appropriate stages.
The presence of a sponsor from among the top management of the company
The presence of a sponsor for a project often predetermines the outcome of the project [3]. Данный фактор имеет особенно большое значение в начале проекта, когда необходимо обеспечить политическую поддержку проекта и необходимые ресурсы; не меньшее значение он имеет в конце проекта, когда необходимо обеспечить принятие и переход к продуктивной эксплуатации системы в полном объеме в запланированный срок.
Fig. 5.1. Модель критических факторов успеха в динамике этапов жизненного цикла информационной системы
Компетентный состав команды
В составе команды проекта должны быть специалисты, обладающие необходимым опытом внедрения ERP-систем, Типична ситуация, когда данная группа представлена консультантами системного интегратора и техническими специалистами вендора. В то же время в проекте необходимо наличие сотрудников самой фирмы, с одной стороны - как основных носителей знаний о бизнес-процессах компании, с другой - для получения знаний о системе и формирования и развития соответствующих компетенций внутри компании [4, 6].
Межфункциональная координация
Интеграционный, т.е. комплексный, характер решения накладывает серьезные требование на межфункциональную координацию, как среди членов проектной команды, так и владельцев бизнес-процессов. Данный фактор имеет высокое значение в начале проекта, когда все участники из различных подразделений формируют общие цели проекта, и в конце, когда необходимо проанализировать достижения соответствующих целей и, убедившись, что не возникло межфункциональных противоречий, завершить проект [4].
Обеспечение "умного" реинжиниринга бизнес-процессов
Построение системы вокруг неоптимизированных процессов не имеет смысла, это чревато "автоматизацией бардака". Владельцы бизнес-процессов должны иметь представление о том, как и какие процессы будут автоматизированы. Во многих методологиях внедрения, включая aSAP, предполагается, что процессы в компании будут по большей части перестроены в соответствии с логикой, реализованной в системе, в связи с чем данный фактор приобретает еще большую значимость. Данный фактор имеет большое значение на фазе концептуального проектирования, когда производится анализ существующих бизнес-процессов и проектирование новых бизнес-процессов в системе.
Привлечение конечных пользователей
С самого начала проекта конечные пользователи должны быть активно вовлечены в проект. Они должны осознавать важность внедрения системы, а их разумные требования не должны быть проигнорированы. Очевидно, что их участие особенно важно на стадии формирования требований к системе, а также при миграции данных и интеграционном тестировании.
Принятие системы сотрудниками
Принятие системы пользователями позволяет в короткие сроки получить запланированный эффект от её внедрения и, следовательно, сократить время окупаемости проекта. Принятие во многом основано на том, понимают ли сотрудники концепцию, реализованную в системе; таким образом, аналогично реинжинирингу бизнес-процессов, данный фактор имеет наибольшую значимость на этапе концептуального проектирования
Мотивация сотрудников и членов проектной команды
Сотрудники должны быть заинтересованы в достижении целей проекта, это снизит возможное сопротивление и повысит лояльность к системе. Также надо иметь в виду, что конфликтующие цели должны быть устранены из системы мотивации сотрудников. Наибольшую значимость данный фактор приобретает на последнем этапе проекта, когда от членов проектной команды требуется наибольшее усилие для обеспечения работоспособности системы и устранения выявленных недостатков.
Продуманная стратегия коммуникаций
Коммуникации как внутри проектной группы, так и за её пределами (с будущими пользователями) являются важным аспектом, обеспечивающим успех проекта внедрения. О целях, задачах и объеме проекта должно быть известно всем участникам проекта; кроме того, участники должны быть в кратчайшие сроки информированы обо всех происходящих изменениях, как внутри проекта, так и в деятельности организации. Для решения задачи регулярной информированности должен быть выстроен план и стратегия коммуникации. Особую важность данный параметр имеет на первых двух стадиях проекта, когда в тесном сотрудничестве с менеджментом компании определяются цели и план проекта; также его значимость повторно возрастает на финальной стадии, ибо на этом этапе проектная команда должна провести большое количество информационных семинаров перед выводом системы в продуктив.
Обеспечение обучения и тренингов
Стратегия и план обучения должны быть сформированы на начальных этапах проекта, а не после его завершения, причем в них должна учитываться необходимость развития компетенции как технических специалистов, администраторов системы, так и конечных пользователей. Кроме того, надо иметь в виду, что при обучении сотрудники должны не только приобретать технические навыки (тренинги) работы в системе, но и получать понимание концепций, реализованных в ERP-системе. Обучение работе в системе должно быть включено отделом управления человеческим капиталом в план развития релевантных сотрудников, а также должна быть предусмотрена возможность обучения новых сотрудников и тех, кому требуется повторное обучение .
Определение списка работ предполагает определение и документирование работ, запланированных для выполнения. Инструментальным средством для определения списка работ, а также для оценки их взаимосвязи и длительности служитиерархическая структура работ ( ИСР ). В предыдущем разделе был рассмотрен вопрос создания иерархической структуры работпутем декомпозиции. Напомним, что результатом процесса декомпозиции является нижний уровень работ, необходимых для завершения проекта, с которым работает руководитель проекта, - уровень пакетов работ. Пакеты работ разбивают на операции. Операция - это единица работ, в результате которой создается конкретный результат по внедрению информационной системы.
Перед началом определения списка работ рекомендуется еще раз проанализировать описание содержания проекта, ограничения и допущения с точки зрения полноты списка операций - этот список будет основой для составления смет, планирования сроков выполнения и контроля проектных работ.
Процесс определения состава операций начинается с определения степени детализации операций. Количество операций должно быть достаточным для того, чтобы ответственный за пакет работ мог отслеживать ход исполнения и осуществлять координациюработ. Число операций не должно быть слишком большим, затрудняющим оценку общего состояния проекта с помощью системы отчетности о ходе выполнения проекта [20]. Например, команда решила ограничить количество операций проекта - не более 30, при этом любая операция должна иметь продолжительность не более 20 дней и не менее 10 дней.
Далее, например, методом мозгового штурма выполняется разбиение пакетов работ на операции. На этом этапе важно проследить, чтобы были определены все операции, необходимые для реализации проекта; при этом длительность (степень детализации) не рассматривается.
На следующем этапе выполняется учет степени детализации. Если количество выделенных операций мало, их разбивают на более мелкие, если велико - родственные операции группируют.
Степень детализации зависит от цели детализации. Детализация операций для разработки иерархического расписания крупного проекта будет существенно отличаться от степени детализации при разработке расписания выполнения малого проекта. Степень детализации также зависит от количества контрольных событий, которые планируется отразить в расписании проекта.
Состав операций может определяться последовательно, методом набегающей волны. Этот метод применяется в крупных или долгосрочных проектах, когда имеется неопределенность относительно выполнения некоторых работ. При использовании метода набегающей волны пакеты работ, расположенные в отдаленном будущем, планируются только на высоком уровне, в то время какпакеты работ, расположенные ближе по оси времени, планируются детально. Этот метод рекомендуется применять при создании детальных планов на стадии разработки и производства.
Исходной информацией для процесса определения списка работ являются [23]:
Для определения списка работ используют следующие инструменты и методы:
Процесс определения списка работ завершается формированием списка операций и уточненным списком контрольных событий .
Список операций - перечень работ , запланированных для выполнения. В список операций входят идентификатор операции и описание содержания работ по каждой операции , подробное настолько, чтобы члены команды проекта понимали, какие работы необходимо провести.
Список контрольных событий - перечень основных событий, которые должны быть включены в расписание для мониторинга хода выполнения и управления проектом, с указанием, является ли контрольное событие обязательным (например, необходимым согласно контракту) или необязательным (например, основывающимся на исторической информации).
Параметры операций расширяют описание операции путем определения ряда элементов, связанных с каждой операцией. Элементы каждой операции формируются с течением времени. На первоначальных стадиях проекта они могут включать в себя идентификатор операции , идентификатор ИСР и название операции , а в конце формирования - коды и описание операции , перечни предшествующих и последующих операций, логические взаимосвязи, опережения и задержки, требования к ресурсам, директивные даты, ограничения и допущения. Параметры операции могут быть использованы для определения лица, ответственного за выполнение работы, географического местоположения выполнения работ и типа операции , например, уровня загрузки, дискретной или распределенной загрузки. Параметры операции нужны для разработки расписания, а также для выбора, систематизации и разнообразных сортировок запланированных операций в отчетах. Количество параметров различается в зависимости от прикладной области.
Запрошенные изменения - изменения в составе работ , которые могут появиться в ходе выполнения работ по реализации ИТ и повлиять на описание содержания проекта
Table 5.2. Пример списка работ.
Наименование пакета работ | Наименование операций |
Обследование |
|
Description of business processes |
|
System development |
|
System testing |
|
Comments
To leave a comment
software project management
Terms: software project management