Lecture
The project charter is a tool that formally authorizes a project and is a link connecting the upcoming project with the current work of the organization. This document usually reflects the situation on the part of the contracting authority, is issued by the manager external to the project, and appoints the project manager, empowering him to use the organization’s resources in the project. This is especially true in function-oriented and matrix organizations , i.e. in those companies where managers have no direct authority over project team members and other resources, but are responsible for the implementation of the project. In order for a statute to be effective in a similar situation, the project manager or project sponsor must be at the level that implies control over resources. Often the date of commencement of the project is the day following the signing of the charter.
The process of developing the project charter already implies that the company is interested in achieving some goal or solving an existing problem and is ready to allocate resources for this. Consequently, from the side of the customer organization there is a motive to invest funds and resources in the generation of such information, which will allow the development of a correct project charter . Information that is key to the drafting of a charter includes:
The decision to implement the project is the result of the project selection process based on the information contained in the above documents. Thus, it is extremely important to give a direct link in the relevant sections of the statute to them in order to give the statute more weight .
In tab. 4.1 shows the requirements for the project charter - lists the required sections with the necessary recommendations and explanations for their content.
Table 4.1. Requirements for the project charter
|
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. |
|
2 |
Business cause of project |
Production need, or the most general description of the project and requirements for the product, the production of which is the result of the project. The formulation of the reason actually answers the question why this project is being carried out. The causes of the project may be based on market requirements, technical progress, legal requirements or state standards. |
|
3 |
Business goal |
Formulated by the customer, based on the strategic and tactical goals of the company, see the section "Formation of the business objectives of the project " |
|
4 |
Requirements to meet the needs , wishes and expectations of the customer , sponsor and other participants of the project |
The vision of the contracting authority, as a rule, is high-level, of ways to achieve a business goal or to solve an existing problem. A project is considered successful if the expectations of the customer and the project participants have been met, therefore, by the time the project charter is formed, its participants should be identified. All requirements documented in the bylaws must be taken into account when performing project valuation. |
|
5 |
Schedule of main control events |
At the stage of forming the charter, the time of the beginning and completion of the project must be indicated; if necessary, key milestones of the project , fundamental for the organization of the customer. It is generally recommended to limit the number of control events to those that are absolutely necessary, i.e. usually three to five. In other words, taking into account the purpose of the charter and the appropriate level of detail, it is completely unnecessary to develop a long list of events - this will only create additional restrictions for choosing a project implementation methodology. In addition, organizations that give a cost value tend to indicate the specifics of a resource budget or a budget for major events [18] |
|
6 |
Project participants |
Enumeration of project stakeholders, in other words, the circle of persons and organizations that are affected by the implementation of this project and who themselves can influence it. For more information about project participants, see the section “Identification of project participants”. |
|
7 |
Project Environment |
Enumeration of all organizational factors characterizing the situation around the project and on the market. It is also necessary to indicate the favorable and unfavorable features of the environment in which the project will be carried out (inside and outside the company), and the ability of the executing organization to implement it, and the customer organization to use its results. Further (see fig. 1.2) one of the effective ways to perform a comprehensive analysis of the environment and the project participants will be shown. When using this approach, a sufficiently large number of factors acting in the project environment are first determined; they are entered into the relevant sector. Then the most critical ones are highlighted (rectangles are participants, ovals are environmental factors) [20] |
|
8 |
Assumptions regarding organization and environment, as well as external assumptions |
A set of conditions that must be fulfilled 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 drafting the project charter, the assumptions are formulated by the contracting authority about the implementing organization |
|
9 |
Restrictions on the organization and environment, as well as external restrictions |
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:
Please note that when drafting the project charter, restrictions are formulated by the contracting authority on the implementing organization and on the project as a whole. |
|
10 |
The amount of money allocated to achieve the business goal |
At this stage, the amount of funds that the contracting authority is ready to allocate to achieve the stated business goals of the project is indicated. This amount is the result of the determination of the order of magnitude and the error in the estimate can range from ~ -20% to + 100% [18] |
|
11 |
Purpose executives project and general definition authority key members project team: RP , sponsor , coordinator |
The project manager is appointed by the project charter and formally proceeds to fulfill his duties on the day after the signing of the project charter. The project manager or manager is primarily responsible for the overall planning, direction and control of the project during all phases of its life cycle, with the goal of obtaining the desired result within the approved budget and schedule. The main task of the project manager is to unite the efforts of all the persons participating in the project. To solve this problem, the project manager is empowered for the project, i.e. the right to give to functional leaders of the project the orders necessary for planning, executing, monitoring, evaluating and controlling the work to be carried out on this project. Project management also includes obtaining information necessary for planning, monitoring, evaluating and controlling the project [8,18]. The role of the project sponsor is usually assumed (not appointed !!!) by a senior manager who acts on behalf of the management of the company financing or executing the project 2 . The key task of the sponsor is to provide project resources, including administrative, as well as to ensure communication between the project and the management of the client organization. On the project, the sponsor is a person who makes decisions that are beyond the authority of the project manager, for example:
The role of a project sponsor usually does not involve working full-time, regardless of the size of the project [8,18]. The project administrator (coordinator) is a specific function on the project that is necessary to support the work related to the administration and documentation of the project organization’s operation and the provision of the project infrastructure. The work of the administrator has as its key task the support of the project manager at the operational level in order to release him for intellectual complex tasks. The duties of the project coordinator may include: administering project contracts and contracts throughout the life cycle, organizing a periodic collection of project implementation status, etc. status collection - a phrase that does not make sense, unless it is a specific term. I ask to pay attention to it. M / b, collecting information about the current status? It is not accepted to form the whole team and moreover immediately specify the names of all its members - functional managers usually allocate their subordinates for the project only when the project manager prepares the resource requirements plan, after determining the scope of the project, and sends a formal request for resources approved by the project sponsor [18] |
Table 4.2. Document control sheet template
|
The authors |
||||
|
File |
||||
|
date of creation |
||||
|
Last edited date |
||||
|
Number of pages |
||||
|
Version |
Date of change |
Brief description of the change |
Change author |
Signature |
|
01 |
||||
|
02 |
||||
|
Document approval |
||||
|
Remarks |
||||
|
No |
receipt date |
Title of the document |
The author of the comment |
Signature |
|
1 . |
||||
|
2 |
||||
|
Processing comments |
||||
|
No |
date of processing |
Version of the document, taking into account the remark |
Executor |
Signature |
|
1 . |
||||
|
2 |
||||
Fig. 4.1. Model of complex analysis of the participants and the project environment (Burnett, 1980). Figure X - sponsor research team
After the preparation of the charter in accordance with the proposed template, it is recommended to check its correctness. The auto-workman, as a rule, the project sponsor, must make sure that:
The project charter is an installation document describing the relationship of the project with the company's operating activities. For this reason, making significant changes to the text of this document is not recommended, and if such a reasonable need arises, it is worthwhile to develop a new project charter that more fully meets the realities of the project being implemented. At the same time, to ensure the control of versioning in the process of drafting the project charter, it is necessary to use so-called document management, presented in Table. 4.2.
A stakeholder (participant, or stakeholder3) is any person who influences the project itself or is affected by the project and the results of its implementation [5].
At the initial phase of the life cycle of the IC, the planning phase, the target group is always the company's management, to which particular attention should be paid and the most closely cooperated with it. In addition, at this phase, the company’s management will be the only point of support for the project in the organization, so you need to be clear about the difference between middle managers and other employees [5].
In general, the process of identifying an interested party should begin with building a map of project participants, where we can immediately classify project participants into various categories. As an example, the following version of the project stakeholder map is presented, shown in Fig. 4.2. The following recommendations should always be kept in mind when developing a stakeholder map
Fig. 4.2. Sample map of project participants (adapted from [5])
1. The organization is not a single entity, but is a set of relationships between different stakeholders. Building a stakeholder map is the first step in identifying the relationships between them.
2. It is necessary to identify all the project participants, and in this aspect the construction of beautiful and unambiguous schemes is secondary to the significance of the formation of an exhaustive list.
3. The stakeholder map is not static, as the project progresses, it will be refined: initially included participants may be excluded from consideration, and at later stages new ones may be identified.
After the identification of interested parties, an analysis of the project participants follows, within which it is necessary to determine the level of impact of each of the stakeholders on the project and assess their involvement in the project.
To analyze the impact of participants on the project, it is recommended to use the template given in Table. 4.3.
Table 4.3. Analysis of the impact of project participants (adapted from [5])
Impact analysis is performed in the context of two aspects.
1. The degree of organizational influence of the project participant
The degree of participation of the project stakeholder in making strategic decisions for the company, its influence on the implementation of various initiatives. It is extremely important in such an analysis not to miss out of consideration and the informal leaders of the organization.
2. The impact of participants on the implemented IT project
This indicator describes how a particular participant can influence a project, how important his support is and how dangerous his rejection of project results is.
Sometimes the results of this analysis can be quite unexpected: change agents from the departments “distant” from the project require much more attention than the staff of the department implementing the project who were in the lower left corner. This analysis allows you to properly prioritize and intensity of use of typically limited resources, including the implementation of the communication strategy.
If the analysis of the impact of participants allows the prioritization of the use of limited project resources, the assessment of engagement allows you to determine the degree of resistance of various project participants, which is characterized by two aspects [5].
1. Trust
As far as the sponsor (s) and other key participants are willing to participate in the project and work with the team before getting the final result, how much can you count on their support at a critical moment on the project?
2. Consent
Did you manage to reach agreement with this particular participant (group of project participants)? Do they share the view of the project manager?
Since in the planning phase of the project, we are mostly talking about senior managers - about the potential sponsors of the project, then the results of this analysis will be more applicable to this category of employees.
Depending on which of the four quadrants of the matrix that one or another participant (group of participants) is in, they belong to the following groups, the principles of work with which are quite different. The project manager needs to establish a constructive dialogue with two groups with a high level of trust, and maintain a reasonable proportion of their participation.
1. Allies
They support the existing expectations on the project, basically share the vision and, most likely, are interested in the results.
2. Competitors
Они заставляют команду руководства проекта постоянно конкурировать за ресурсы, обосновывать значимость проекта и искать наиболее оптимальные и менее затратные способы реализации запланированного - по сути, таким образом, выявляя в последних лучшее.
Спонсоры и ключевые участники проекта, обладающие низким уровнем доверия, характеризуются также низким уровнем готовности работать над проектом. Две группы, которые относятся к данной категории, - это партнеры и противники.
3. Партнеры
На первый взгляд, с ними удалось прийти к согласию, но первые их действия свидетельствуют о нерешительности и несоответствии заявленному. Рекомендуется с каждым участником данной категории провести личную беседу, касающуюся его роли на проекте, касающееся их обязательств, для идентификации причин, не позволяющих им действовать более решительно и организованно.
4. Противники
В отличие от партнеров признают свою неготовность действовать - но конфликт с людьми, открыто выражающими свою позицию, маловероятен, поэтому действия по вовлечению их в проект аналогичны действиям по отношению к партнерам: общение, беседапо вопросам их обязанностей и ответственности.
На крупных проектах рекомендуется создавать базу данных участников проекта, в которой будет храниться информация о сотрудниках, способных, так или иначе, оказать влияние на результаты реализации проекта. Хранимая информация включает в себя:
Наличие такой базы данных позволяет менеджеру проекта, во-первых, держать информацию об участниках проекта всегда под рукой, а во-вторых, избегать неловких ситуаций, когда менеджер забывает с кем-то лично побеседовать.
Данный процесс направлен на изучение требований заказчика, которые должны быть уже отражены в уставе проекта, и перенос их в более конкретные термины требований проекта, на основе которых уже формируется список проектных работ и программакачества проекта. Для получения корректной информации необходимо в самом начале правильно организовать ее сбор, который на ИТ-проектах чаще всего реализуется в форме интервью с заказчиком (см. рис. 4.2).
Организация и проведение результативного интервью
1. Подготовка
Изначально необходимо точно сформулировать основные идеи, которые определяют цель визита к заказчику. Участники команды проекта должны очень ясно представлять себе, какого рода информация нужна и каким образом она будет использована, с тем чтобы точно определить целевую аудиторию. Только после этого необходимо переходить к разработке списка вопросов, которые будут заданы заказчику.
Основная рекомендация для проведения интервью для формирования функциональных требований к системе - использовать подход, применяемый в структурном моделировании, то есть постараться задать вопросы и получить информацию в разрезе, как показано на рис. 4.2.
o "Большая картинка"
o Описание процесса
o Документы
2. Проведение
Рекомендуется планировать интервью исходя из максимальной продолжительности в 1,5 часа. Учитывая весьма ограниченное время, необходимо всегда приходить в указанный час, заранее продумать маршруты пути к месту встречи. Каждый участвующий в процессе общения с заказчиком должен оперировать одним и тем же набором вопросов в одинаковой последовательности, чтобы обеспечить порядок проведения переговоров и удобство при дальнейшем формировании протокола интервью.
Fig. 4.2. Принцип структурирования информации о бизнес-процессе
На практике для проведения интервью часто составляют команды по два человека, это удобно с той точки зрения, что один задает вопросы, а другой делает пометки. В то же время присутствие на встрече более двух интервьюеров способно значительно повредить общению.
Дальнейшие действия
После завершения всех встреч нужно собрать полученную информацию в единый отчет, который будет полезен проекту. Обычно это реализуется при тесном взаимодействии всех участников интервью, в том числе и интервьюированных представителей заказчика, которые согласуют подготовленный сводный протокол интервью.
В качестве отчета по интервью готовится сводный протокол, который затем отправляется на согласование. Пример шаблона протокола представлен в табл. 4.4.
Крайне важным моментом является "встраивание" информации, полученной на интервью от заказчика, в проектную документацию - иначе вся собранная информация не имеет никакого значения для проекта. Для того чтобы проверить, были ли учтены требования заказчика в проектных спецификациях, рекомендуется ответить на следующие вопросы:
Определены ли факторы ценности для заказчика?
Усвоила ли команда проекта эти факторы?
Были ли факторы ценности интегрированы в процессы и проектные продукты?
Инструментом, который позволяет обеспечить положительные ответы на эти вопросы, является функция качества или "дом качества", речь о котором пойдет ниже, в разделе, посвященном формированию требований проекта.
Таблица 4.4. Шаблон протокола интервью
|
УПРАВЛЕНИЕ ДОКУМЕНТОМ |
|||
|
Author |
|||
|
date of creation |
|||
|
ИНФОРМАЦИЯ О ВСТРЕЧЕ |
|||
|
Время и дата |
|||
|
Serial number |
|||
|
Адрес/ место |
|||
|
УЧАСТНИКИ ВСТРЕЧИ |
|||
|
Со стороны заказчика |
[ФИО, должность] |
||
|
Со стороны исполнителя |
[ФИО, должность] |
||
|
РЕЗУЛЬТАТЫ ОБСУЖДЕНИЯ |
|||
|
Пункт повестки/ вопрос |
Результаты обсуждения |
Ответственный |
Сроки выполнения |
|
. |
|||
|
. |
|||
|
. |
|||
|
СТАТУС ПРОТОКОЛА |
|||
|
Согласовано |
[ФИО, должность] |
||
|
Утверждено |
[ФИО, должность] |
||
|
ИНФОРМАЦИЯ О СЛЕДУЮЩЕЙ ВСТРЕЧЕ |
|||
|
Время/ Дата |
|||
|
A place |
|||
Использование функции качества
Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.
Процесс построения "дома качества" - предельно сложная процедура, особенно в случае крупных проектов. Тем не менее, этот инструмент довольно удобен в использовании и значительно повышает качество процесса управления требованиями проекта.
In fig. 4.3 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.
1. Подготовка требований заказчика
Fig. 4.3. Схема и рекомендации по проведению интервью
Требования заказчика - важнейшая информация при построении "дома качества". Как правило, это самый сложный этап, поскольку необходимо выяснить наиболее значимые условия заказчика. Основной объем информации о его потребностях был выявлен в процессе интервьюирования и на этапе подготовке ТЭО и устава проекта. При разработке функции качества рекомендуется ограничивать функцию качества 10-ю требованиями заказчика, в противном случае использование инструмента становится громоздким.
2. Определение требований проекта
Fig. 4.4. Функция качества проекта ("домик" качества)
В отличие от требований заказчика, требования проекта сформулированы в терминах конкретных действий, при помощи которых команда планирует и реализует проект. Сформулированные таким образом требования проекта должны быть доступны для выполнения измерения и контроля достижения по завершению проекта. Следует различать два вида требований проекта: условия заказчика и предложения команды для их выполнения, как правило, содержащиеся в соответствующей методологии.
3. Формирование матрицы взаимосвязей
На этом этапе происходит проверка отсутствия взаимных противоречий между сформулированными требованиями проекта, иными словами, происходит их попарное сравнение. Для обозначения связи могут использоваться разные символы: так, для показа положительной связи часто используют o, а для показа отрицательной - o. Идентифицированные отношения демонстрируют столкновение требований и возможность нахождения компромисса между ними, что позволяет увидеть условия проекта в совокупности, а не по отдельности.
4. Формирование матрицы отношений
Заполнение матрицы отношений есть ключевой шаг построения "дома качества". Смысл ее заполнения состоит в том, чтобы убедиться, что все требования заказчика будут удовлетворены предложенными требованиями проекта. На пересечении соответствующего требования заказчика и требования проекта при наличии положительной связи ставится отметка, например, крестик. Если требование заказчика не поддерживается ни одним требованием проекта, значит, удовлетворение первого может вызвать ряд проблем. В обратной ситуации, когда проектное требование не соотносится ни с одним требованием заказчика, говорят об избыточности данного проектного требования. На крупных проектах иногда усложняют отношения между требованиями заказчика и проекта и вместо крестика используют числовые значения, характеризующие степень влияния требований проекта на реализацию заданного требования заказчика [5].
5. Субъективная оценка через сравнительный анализ
На данном этапе происходит присвоение степени важности каждому требованию заказчика и проект сравнивается с другими проектами и/или текущим status quo. Сравнение выявляет сильные и слабые стороны проекта по отношению к аналогичным инициативам, определяет возможности для улучшения.
6. Объективная оценка через установку конечных целей
Для обеспечения измерения и последующего контроля реализации требований проекта (а через них - и обеспечения требований заказчика) необходимо задать измеримые конечные цели по каждому требованию проекта, тем самым обеспечив объективную основу для управления ими.
Comments
To leave a comment
software project management
Terms: software project management