Lecture
The process of determining the interrelationships of operations involves identifying and documenting the logical interrelationships between planned operations. Determining relationships requires a good knowledge of technology and project priorities.
The interconnections of operations can be sequential, with their own precedence relationships, as well as with advances and delays. In this case, each output element of the operation is used as an input element of another operation or is part of the delivery. Interrelations of operations can be with overlappings, when an operation still under construction has enough output elements to start an operation dependent on it, or with parallel execution of operations [1].
The initial information for the process of determining the relationship of operations can be [11]:
1. Description of the project content - contains the definition of the product content, which includes the characteristics of the product that may affect the definition of interrelationships of operations, therefore, in order to avoid errors, the definition of the product content should be reanalyzed;
2. methodology for the implementation of IP;
3. the results of the process of determining the composition of operations;
4. list of operations;
5. parameters of operations ;
6. list of control events ;
7. approved change requests.
8. In determining the relationship using the following tools and methods.
9. The precedence method: a method for constructing network diagrams of a project schedule, in which operations are depicted as rectangles (called “nodes”), and dependencies are arcs connecting them. This method is also called "operations in nodes"; it is used in most project management software packages.
10. Method of arrow diagrams: a method for constructing network diagrams of a project schedule, where operations are represented as arcs that are connected in nodes showing their dependencies. This method is also called "operations on arcs".
11. Network schedule templates. Standardized project scheduling network diagram templates can be used to speed up the preparation of project planning network operations. They can include both the entire project as a whole and its part.
12. Determination of dependencies. Three types of dependencies are used to determine the sequence of operations: hard (or mandatory), non-rigid (or arbitrary), and external.
13. Application of advances and delays. Leads and delays are time intervals that modify the relationship between previous and next operations.
14. The process of determining the relationship of operations ends with the formation of the following documents.
15. Network diagrams of the project schedule - a schematic display of the planned operations of the project and logical relationships (dependencies) between them. The network diagram of the project schedule can be built manually or with the help of project management software, for example, Spider or MS Project. It may include a complete specification of the project or one or more summary operations (package of operations). In fig. 7.1 is an example of the presentation of the project schedule in the form of a MS Project Gantt chart.
16. List of operations (updates). If the approved change requests are the result of an activity interrelationship process, then an updated list of operations is created that includes these changes.
Fig. 7.1. Fragment of the project schedule in the form of a Gantt chart MS Project
Operation parameters (updates). If approved change requests resulting from the process of defining the relationships between operations affect the list of operations, then these approved changes are included in the relevant elements of the operation parameters (logical relationships and corresponding advances and delays).
Requested changes. In the development of logical relationships, advances and delays of the project can be identified points that will entail a request to change the list of operations or parameters of operations. The requested changes are reviewed and approved as part of the overall change management process.
The assessment of the resources of each planned operation is designed to determine which resources (human resources, equipment) will be used and in what quantity and when each of the resources will be available for the implementation of project operations. The process of evaluating the resources of operations is closely coordinated with the process of estimating the cost, which will be discussed in the project cost management section.
As an example, consider an assessment of the need for human resources. To allocate resources, you need to figure out what resources are needed, their availability, availability and the necessary amount. To answer these questions is required to keep records of resources and their parameters. We give an approximate composition of parameters for the assessment of human resources:
1. Full name;
2. age;
3. education;
4. refresher courses;
5. position in the company;
6. brief description;
7. list of projects in which he participated, the role and scope of work, the quality of the work done;
8. work schedule (is the basis for the resource calendar);
9. accessibility (availability ratio, vacations, sick-lists, exhibitions, etc.).
In some companies, in order to determine the availability of a resource, the item “Availability” reflects the period of regular actual absence of an employee at work related to vacations, participation in annual exhibitions, business trips, etc. This allows you to predict the possible absence of the employee with his participation in the project. Another equally important component of the "availability" parameter is the availability ratio. It means the part of the working time during which the employee can work on projects at the rate of an 8-hour working day.
Baseline information to determine the complexity are:
In fig. 7.2 shows a fragment of a Gantt chart with reference to resources.
When determining the labor costs for carrying out project operations, regulations and GOSTs are used. In tab. 7.1 presents the standards for the preparation of basic types of documents at various stages of the development of documents for automated systems (AS), as well as the required qualifications of the developers of documents.
Fig. 7.2. Fragment of the Gantt chart with reference to resources
Table 7.1. Standards of labor input for the development of documents at the NPP
Title of the document | Unit of work | Standard time, h | Executive qualification |
The list of tasks for the development of specialized (new) hardware | Position | 0.14 | Engineer |
List of input signals and data | Also | Also | Also |
List of output signals (documents) | Also | Also | Also |
Hardware Specification | Also | Also | Also |
The list of tasks for the development of construction, electrical, sanitary and other sections of the project related to the creation of the system | Also | Also | Also |
Description of automated functions | Sheet f. A4 | 4.30 | Lead Engineer |
Description of the tasks (complex tasks) | Also | Also | Also |
Description of the information support system | Also | Also | Also |
Description of the organization of the information base | Also | Also | Also |
Description of classification and coding systems | Also | Also | Also |
Description of the array of information | Also | Also | Also |
Description of the complex of technical means | Also | Also | Also |
Software Description | Also | Also | Also |
Description of the algorithm ( project procedure ) | Also | Also | Also |
Description of the organizational structure | Also | Also | Also |
Description of data processing (including teleprocessing) | Also | Also | Also |
General system description | Also | Also | Also |
Statement of the need for materials | Position | 0.27 | Engineer |
Machine Data Sheet | Also | Also | Also |
Input Array | Sheet f. A4 | 0.90 | Technician |
Database directory | Also | Also | Also |
The composition of the output (messages) | Also | Also | Also |
Technological instruction | Also | 3.00 | Senior engineer |
Instructions for the formation and maintenance of a database (data set) | Also | Also | Also |
User's manual | Also | 3.15 | Engineer |
Instructions for use KTS | Also | Also | Also |
The duration of the operation is the length of time it takes to complete the operation. Duration can be measured by the number of days during which a person (or several people) worked on this operation. The process of estimating the duration of planned operations uses information on the content of the operation, the required resources, the calendars of the resources, indicating their availability and the effort required to complete the operation. The estimated duration can be refined during the course of the project.
Fig. 7.3. Resource Gantt Chart
The process of evaluating the duration of operations requires that the amount of work, the estimated amount of resources be estimated and the number of workers be determined. Assessment of the duration of the operation is performed using the SRI.
The total project duration is calculated as the output of the schedule development process.
Background information for determining the duration of operations
The project management plan includes a register of identified risks that the team considers when preparing an estimate of the duration of the operations and adjusting it to the risks.
The following tools and methods can be used to determine the duration of operations.
An estimate by peers implies an assessment of the actual duration of a similar previous planned operation as a basis for estimating the duration of a future planned operation and uses historical information and expert judgment.
Parametric estimation. The estimated duration of operations can be calculated by multiplying the amount of work by labor productivity. To determine the duration of operations for working periods, the total amount of resources is multiplied by the number of working hours or productivity during the working period and divided by the number of attracted resources.
Score by three points. The accuracy of the assessment of the duration of operations can be increased if the size of risks is taken into account in the initial assessment. The three-point estimate is based on the definition of three types of ratings:
Duration of operation = (optimistic + [4 * most likely estimate] + pessimistic) / 6
The results of the process of assessing the duration of operations
Estimation of the duration of operations. Quantitative estimates of the likely number of working periods that will be required to complete an operation always include estimates of the ranges of possible values. For example, a rating of “2 weeks 2 days” means that a planned operation will be performed for at least 8 days and no more than 12 (with a 5-day working week).
Operation parameters (updates). Operational parameters are updated each time the duration of planned operations changes, assumptions made when estimating the duration of operations, and the various reserves foreseen in the event of unforeseen circumstances.
Valuation is the process of establishing the cost of a project’s resources based on certain facts and assumptions. To determine the valuation, first of all, it is necessary to determine the operations (package of operations), the duration of the operations and the required resources. The assessment process and its result largely depend on the accuracy of the description of the content, the quality of the available information, on the project stage. The process of valuation is influenced by the time allotted for the operation being evaluated, the experience of the manager, the assessment tools, and the specified accuracy. Оценка стоимости проекта начинается на пред-проектной стадии (до заключения контракта) и выполняется в течение всего времени выполнения проекта. Выделяют следующие оценки стоимости:
На предпроектной стадии первоначально может определяться только порядок величины стоимости. Точность оценки порядка величины стоимости проекта может колебаться от -50% до +100%. Точность концептуальной оценки находится в интервале -30% - +50%. Точность предварительной оценки проекта колеблется от -20% до +30%. На этапе окончательной оценки точностьколеблется от -15% до +20%. Контрольная оценка имеет точность от -10% до +15%. Таким образом, каждая последующая стадия жизненного цикла проекта имеет более точную стоимостную оценку (см. рис. 7.4).
Fig. 7.4. Классификация типов оценок стоимости
Стоимостная оценка обычно выражается в единицах валюты (доллары, рубли и т. д.) для облегчения сравнения проектов и операций внутри проекта.
Стоимость плановых операций оценивается для всех ресурсов, задействованных в проекте. К ресурсам относятся, в частности, специалисты, оборудование, телефонная связь, Интернет, арендованные помещения, а также особые статьи расходов, например, учет уровня инфляции или расходы на непредвиденные обстоятельства.
На фазе планирования проекта имеет смысл использовать менее точные и менее затратные способы оценки стоимости.
К сведениям, имеющим большую важность для успешной реализации оценки стоимости, относятся:
Первые определяют структуру основных элементов оценки, вторые необходимо принимать по части обеспечения персоналом и аутсорсинга, что является ключевым элементом калькуляции себестоимости проекта.
Оценка "сверху вниз" применяется на ранних стадиях в условиях недостаточной информации о проекте. Производится только одна оценка стоимости всего проекта на самом верхнем уровне. Такая оценка не требует больших усилий, но имеет низкуюточность.
Оценка по аналогам представляет вид оценки "сверху вниз". Она подразумевает оценку текущего проекта, называемого целевым, на основе фактической стоимости одного или нескольких предыдущих проектов (аналогичных или исходных) близкого размера, сложности и содержания. Менеджеры, выполняющие оценку, могут опираться на инстинктивное чутье, исторические данные или приблизительные расчеты, модифицированные так, чтобы учесть любые различия между целевым и аналогичным проектами. При наличии очень похожего проекта оценка может быть довольно точной. Такой тип оценки применяется на любом этапе жизненного цикла проекта. Оценка по аналогам не требует больших усилий при гарантированной точности, однако не всегда удается найти и определить схожие проекты. Точность оценки по аналогии колеблется от -30% до +50%. Стоимостьподготовки такой оценки составляет 0,04%-0,15% от общей стоимости проекта.
Процесс выработки оценки по аналогии включает в себя определение специфики предварительного планирования: конечныепользователи, цель и формат оценивания, список участников процесса и их роли, доступные ресурсы. Затем следует изучение целевого проекта: его содержания, размера и показателей сложности. Далее происходит обращение к базе данных предыдущих проектов с целью их оценки. Наиболее подходящий проект (или проекты) отбирается в качестве аналогов. Соотнесение проекта-аналога и проекта-цели сложностей не вызывает, поскольку они наделены сходным набором характеристик. Затем следует перенести решение, которое позволило достичь цели при выполнении аналога, на целевой проект, корректируя элементы, не имеющие полного соответствия.
Чтобы получить денежный эквивалент затраченного времени, нужно умножить количество часов на расценки. Сумма всех оцененных элементов равна общей оценке проекта. Для менеджеров крайне важно умение выявлять скрытые различия между элементами исходного и целевого проектов и оценивать стоимость элемента целевого проекта на основе исходного, в действительности являющегося подобным или аналогичным. Проверка, пересмотр и улучшение, как было сказано в предыдущем разделе, представляют собой финальный шаг в разработке оценки по аналогии.
Оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует.
Параметрическая оценка применяется на ранних этапах проекта. Процесс параметрической оценки состоит в определении параметров оцениваемого проекта, которые изменяются пропорционально стоимости проекта. На основании одного или нескольких параметров создается математическая модель. Например, в качестве параметра разработки программного обеспечения может быть выбрана стоимость разработки строки кода. Для оценки стоимости обследования может быть выбрано количество автоматизируемых бизнес-процессов. Наиболее распространенным параметром оценки стоимости IT-проектов является количество требуемого рабочего времени на выполнение операций (пакета операций). При тесной связи между стоимостью и параметрами проекта и при возможности точного измерения параметров можно увеличить точность расчетов. Преимущество данного метода - для оценки стоимости проекта достаточно знать "ставки" привлекаемых ресурсов; недостатком является низкая точность (-30%-+50%). Стоимость подготовки параметрической оценки составляет 0,04%-0,45% от общей стоимости проекта.
Для того чтобы разработать параметрическую оценку надлежащего качества, необходимо собрать качественную исходную информацию, в которую должны входить [18]:
Параметрические оценки наиболее часто применяются на стадии определения проекта и на начальных стадиях проектирования, когда еще нет достаточного количества информации для разработки восходящей оценки.
Стоимостная оценка должна производиться компетентными сотрудниками, определение которых можно произвести в соответствии со следующими критериями [8].
1. Специалисты, выносящие оценки, должны обладать достаточным опытом в реализации той работы, оценку которой они производят. Оценки на основе любых методов основываются на понимании работы, которую предстоит выполнять.
2. Для выполнения оценки необходимо привлекать непосредственных исполнителей: с одной стороны, это позволит им сразу понять, в рамках каких ограничений им предстоит работать, с другой - у людей появляется гораздо больше мотивации работать с этими оценками, чем с данными, предоставленными кем-то другим.
3. Специалисты, выносящие оценки, должны точно представлять себе цель производимой оценки, иначе можно получить весьма неточные результаты, пригодные лишь для идеальных условий.
Один из способов зафиксировать результаты оценки стоимости проекта - формирование сметы проекта, документа, отражающего разбивку стоимости проекта по основным категориям затрат проекта. Приведенный ниже подход к формированию сметы в большей степени соответствует параметрическому методу оценки стоимости проекта: нами выделены различные параметры, характеризующие стоимость проекта, предложена их цена за единицу и установлен коэффициент для расчета итоговых затрат по категории.
Шаблон сметы проекта. Проверка качества составления сметы проекта
Приведенный ниже контрольный список содержит пункты, рекомендованные применительно к сметам проектов.
Исходной информацией для процесса разработки расписания является описание содержания проекта. Оно включает допущения (документированные факторы, относящиеся к расписанию, которые при разработке расписания считаются достоверными) и ограничения (факторы, ограничивающие свободу выбора команды управления проектом при проведении анализа сети расписания и влияющие на составление расписания проекта). При разработке расписания учитываются два основных типа ограничений по времени:
Для разработки расписания рекомендуется использовать следующие инструменты и методы.
Диаграмма Гантта - диаграмма, которая использует горизонтальные полосы для представления операций проекта, показывает даты начала и завершения каждой операции и проекта относительно горизонтальной шкалы времени [18].
Диаграмма, построенная по методу критического пути - методу анализа сети расписания, проводимого при помощи модели расписания. Критический путь представляет группу операций, которые не могут быть задержаны без изменения отсрочки, даты завершения всего проекта [23].
При использовании метода критического пути рассчитываются теоретические даты раннего старта и раннего финиша и позднего старта и позднего финиша для всех плановых операций без учета ограничений по ресурсам. Этот расчет производится путем проведения анализа прямого и обратного проходов по путям сети расписания проекта. Полученные даты раннего и позднего старта и финиша показывают периоды времени, в пределах которых следует планировать данную операцию, исходя из ее длительности, логических взаимосвязей, опережений, задержек и прочих ограничений [11].
Диаграмма контрольных событий - инструмент для разработки расписания проекта, построение которого включает следующие действия [18]:
Результатами процесса разработки расписания являются:
При разработке расписания рекомендуется соблюдать следующую последовательность работ [23]:
Переход от списка операций к календарному плану удобно выполнять с помощью заполнения шаблона, состоящего из нескольких таблиц (см. табл. 7.2).
Table 7.2. Шаблон последовательного формирования расписания проекта
Список операций | Итерационная детализация информации об операциях | ||||||
Номер задачи | Номер ИСР | Описание задачи | |||||
Предшествущие задачи и продолжительность их выполнения | |||||||
Номер задачи | Номер ИСР | Описание задачи | Предшествующая задача | Оценка трудоемкости (человеко-дни) | |||
Распределение задач по ролям (исполнителям) | |||||||
Номер задачи | Номер ИСР | Описание задачи | Предшествующая задача | Оценка трудоемкости (человеко-дни) | Executor | ||
Calendar plan | |||||||
Номер задачи | Номер ИСР | Описание задачи | Предшествующая задача | Оценка трудоемкости (человеко-дни) | Executor | Start | Завершение |
The following is an example of its use for the project preparation phase (see Table 7.3).
Table 7.3. An example of using the pattern of sequential scheduling
List of works | ||
Task number | ISR number | Task Description |
1.1 Project preparation | 1.1 | Project initiation meeting |
1.2 | Carrying out communication to key departments of the alert of key departments and business units of the company about the start of the project | |
1.3 | Creating a working environment for the project team | |
1.4 | Signing contracts | |
1.5 | Creation and mobilization of the project team | |
1.6 | Creating and issuing a project guidance document | |
1.7 | Setting the project management process |
Logical sequence and complexity of work
Task number | ISR number | Task Description | previous tasks | Estimated labor (people * days) |
1.1 Project preparation | 1.1 | Project initiation meeting | 2d | |
1.2 | Conducting communication to key departments and business units that alert key departments and business units of the company about the start of the project | 1.1 | 5d | |
1.3 | Creating a working environment for the project team | 1.1 | 5d | |
1.4 | Signing contracts | 1.1 | 5d | |
1.5 | Creation and mobilization of the project team | 1.2 | 10d | |
1.6 | Creating and issuing a project guidance document | 1.5 | 15e | |
1.7 | Setting the project management process | 1.6 | 1e |
Securing the roles of performers for design work
Task number | ISR number | Task Description | No pre-shevt.zadachi | Evaluation of labor intensity (people * days) | The role of the performer |
1.1 Preparatory Project | 1.1 | Project initiation meeting | 2d | Project sponsor; project Manager; solution architect; project administrator | |
1.2 | Communication to key departments and business units to notify key departments and business units of the company about the start of the project | 1.1 | 5d | Project sponsor; project Manager; project administrator | |
1.3 | Creating a working environment for the project team | 1.1 | 5d | Project Administrator; project sponsor | |
1.4 | Signing contracts | 1.1 | 5d | Project sponsor; project Manager; project administrator | |
1.5 | Creation and mobilization of the project team | 1.2 | 10d | Project Manager; team leader for integration and development | |
1.6 | Creating and issuing a project guidance document | 1.5 | 15e | Project sponsor ; project Manager | |
1.7 | Setting the project management process | 1.6 | 1e | Project sponsor; project Manager; project administrator |
Securing the roles of performers for design work
Task number | ISR number | Task Description | No pre-shevt.zadachi | Evaluation of labor intensity (people * days) | The role of the performer |
1.1 Preparatory project | 1.1 | Project initiation meeting | 2d | Project sponsor; project Manager; solution architect; project administrator | |
1.2 | Communication to key departments and business units to notify key departments and business units of the company about the start of the project | 1.1 | 5d | Project sponsor; project Manager; project administrator | |
1.3 | Creating a working environment for the project team | 1.1 | 5d | Project Administrator; project sponsor | |
1.4 | Signing contracts | 1.1 | 5d | Project sponsor; project Manager; project administrator | |
1.5 | Creation and mobilization of the project team | 1.2 | 10d | Project Manager; team leader for integration and development | |
1.6 | Creating and issuing a project guidance document | 1.5 | 15e | Project sponsor ; project Manager | |
1.7 | Setting the project management process | 1.6 | 1e | Project sponsor; project Manager; project administrator |
In many ways, the sequence of steps when creating a schedule in this way is similar to the set already discussed earlier, but within the framework of this method, the calculation of the critical path becomes a key element. So, consider an example of developing a project schedule using the critical path method [18].
Used ISR, the list is identical to the lower level of the hierarchical structure of the work.
The duration of each operation was determined in the framework of the processes for assessing the labor intensity and determining the duration of operations (see the relevant sections of the publication).
The previous operation of each operation was determined during the final stages of the hierarchical structure of work (see the relevant sections of the publication).
When calculating an early schedule for operations, you must adhere to several scheduling conventions. These rules are adopted by the scheduling community. In the schedule, the start of the first operation is always assigned to the start date of the project. This date is the entrance to the project plan. The first start date is the start of the project. The early finish date is the early start date plus the duration of the operation. The following rule applies. Each operation is considered to begin at the beginning of the period in which it starts, and ends at the end of the period in which it ends. This means that if the duration of the operation is one day and if it starts on the first of January, then the operation also ends on the first of January. In accordance with this rule, the early finish of any operation is equal to the early start plus the duration minus one. Thus, operation 1 begins on day 1 and ends on day 15 (see Table 7.4). The next operation should start on the next available time period: since operation 1 ends on day 15, operation 2 should start on day 16 and end on day 20. Operations 3 and 4 present the following problem. These operations depend on operation 2, i.e. operation 2 must end before they start. Obviously, the date of the early start of both operations will be day 21.
Formula 1. Calculation of the early finish
EF = ES + Duration - 1
To perform the back pass, you must start with the last operation that was performed in the early schedule. The rationale for this is the following: if the earliest schedule defines the earliest project completion date, then in the backward passage we look for the latest dates for all operations for which the project could be fully completed. We start at the latest of the early finish dates, corresponding to the completion of the last operation. This is a late finish time (LF). To get the late start time (LS), the duration is subtracted from the late finish time. The dates of the late schedule (late start and late finish) for operation 11 will be days 90 and 94 respectively. Since the date of late start of operation 11 is day 90, operations 10 and 3 must be completed no later than day 89. This will be the date of late finish for both operations . This is the latest deadline for completing these operations in order to ensure the completion of the project on day 94 and the date of the late start of operation 11. For getting the dates of late start, the duration of each operation is subtracted. When considering operation 2, you must be very careful in choosing a late finish date, which is also consistent with the late start dates of operations 3, 4 and 6. Since the dates of late start of operations 3, 4 and 6 are days 86, 53 and 21, respectively, the date of late finish of operation 2 is day 20.
Table 7.4. Project operations
Operations | Description | Duration | Predecessor operation | ES | EF | LS | Lf | Time reserve |
one | Definition of project output | 15 | - | one | 15 | one | 15 | 0 |
2 | Approval by interested parties | five | one | sixteen | 20 | sixteen | 20 | 0 |
3 | Choosing a place | four | 2 | 21 | 24 | 86 | 89 | 65 |
four | Evaluation and selection of a supplier | four | 2 | 21 | 24 | 53 | 56 | 32 |
five | Acquisition of hardware | 3 | four | 25 | 27 | 57 | 59 | 32 |
6 | Software design | 15 | 2 | 21 | 35 | 21 | 35 | 0 |
7 | Code writing | thirty | 6 | 36 | 65 | 36 | 65 | 0 |
eight | Software Testing | four | 7 | 66 | 69 | 66 | 69 | 0 |
9 | Hardware testing | ten | five | 28 | 37 | 60 | 69 | 32 |
ten | Hardware and software integration | 20 | 9.8 | 70 | 89 | 70 | 89 | 0 |
eleven | Installation and final acceptance | five | 3.10 | 90 | 94 | 90 | 94 | 0 |
Formula 2. Calculation of the late finish
LS = LF - Duration + 1
When calculating the dates of the early and late schedules of the project, it is found that sometimes the dates of the early and late schedules are the same, and for some operations they are different. In these operations, there was a difference between the date of early start and late start. The difference between these dates is called a temporary reserve (float or slack). The operation time reserve is the amount of time for which the operation can be delayed without causing a delay in the completion of the project. To calculate the time reserve of each operation, you must subtract the date of early start from the date of late start of the operation. The time reserve can also be calculated by subtracting the early finish date from the late finish date, since the difference between the start and end dates is the duration of the operation, which remains unchanged for the early and late schedules.
Formula 3. The calculation of the temporary reserve
float = LS - ES = LF - ES
The critical path (critical path) is a sequence of operations that have zero time reserve (zero float). Operations with a zero temporary reserve are operations whose delay necessarily entails a delay in the completion of the entire project. Operations of this type must be strictly controlled in order to ensure that the project is completed at the scheduled time. Conversely, operations that do not lie on a critical path and have a non-zero time reserve need not be so strictly controlled. In addition, it is important to know which project operations can be delayed without changing the project completion date. Resources of operations with time reserve, if necessary, can be used to perform a bypass (workaround).
After the schedule for the earliest end of the project has been determined, it should be checked on real data. The schedule must determine the project end date, earlier than the date
commitments (promise date), which could already have been communicated to project participants. If this is not the case, it is necessary to sound the alarm. The compiled schedule does not yet include delays that may occur in the absence of the necessary resources. The schedule is not supplemented by reserves in case of known or unknown risks. Also, normal deviations were not taken into account, which will occur between the predetermined and actual duration of the project operations.
Then you need to adjust the schedule or date of commitment. Two situations are possible: a schedule with a commitment date earlier than a predetermined date, and a schedule with a commitment date later than a predetermined date. If the tentative date of the schedule is later than the commitment, then it is necessary to apply compression (crashing) or fast tracking (tracking).
The disadvantage of these methods for any schedule is that the project cost or risks increase, and in some cases both. Principles of application of these methods will be discussed in sections on the design phase of the life cycle of IP.
Schedule management is associated with determining the current state of a project schedule, influencing factors that create changes in a schedule, identifying facts about changes to a project schedule, and managing changes. Schedule management is considered part of the overall change management process.
Baseline Information for the Schedule Management Process
The schedule management plan determines how the project schedule will be monitored and managed.
The baseline schedule is a component of the project management plan and the basis for measuring the execution of the schedule and reporting on it within the framework of the basic execution plan.
Task reports provide scheduling information.
Approved change requests are used to update the baseline schedule and other components of the plan.
Schedule management is performed using the following tools and methods.
1. Reporting on the progress of the project includes the actual dates of commencement and completion and the remaining duration of uncompleted planned operations. When using the method of mastered volume reporting may contain the percentage of the current planned operations. To simplify the preparation of periodic reporting on project progress, it is convenient to use standard forms - templates. An example of a reporting form template is presented in Table. 7.5.
Table 7.5. Project Progress Report Form Template
"Name of the project" Weekly status report Reporting period: | |||||||
To : | |||||||
From : | |||||||
Date : | |||||||
Works performed in the reporting period | |||||||
No | Operation name | Planned danachala | Planned end date | Deviation | Expected End Date | % completion | Comment |
The name of the package operations | |||||||
1 . | |||||||
The name of the package operations | |||||||
2 | |||||||
3 | |||||||
Conclusions and offers | |||||||
Conclusions : | |||||||
Suggestions : | |||||||
Open questions and problems | |||||||
No | Journal number | Description | Decision / Decision Project | Term of the decision | Responsible | A priority | |
The schedule change management system should be coordinated with the project’s integrated change management procedures and determine the procedure for changing the project schedule; includes work with documents, tracking systems and authorization levels required to authorize changes; is part of the overall change management process.
Performance measurement Methods of measuring efficiency give a deviation in terms and a deadline index used to estimate the magnitude of any deviations from the schedule.
Variance analysis. A key function of schedule management is to conduct a variance analysis by time. A comparison of the policy start and execution dates with actual / predictable gives information to take corrective action in the event of a delay.
Comparative timetables. To simplify the analysis of the execution of the schedule, it is convenient to use a comparative bar chart that has two columns for each planned operation — the current state and the state of the approved basic schedule plan. The diagram clearly shows the places where the schedule overtakes the planned one and where it lags behind.
Line of execution
The execution line shows how much time each project operation is ahead of or lags behind the base schedule [18].
To the left of the execution line, the completed share of each operation is shown, to the right, the remaining share. According to Dragan Z. Milosevic [18], in advanced recent applications, the execution balance line is considered as one of the steps of proactive schedule management. The amount of time the operation lags behind the baseline is used to adjust the effects to eliminate possible delays.
Construction of the project execution line
1. Preparation of information for building a line of execution: the basic schedule in the format of a Gantt chart, reports on the progress of the project, requests for changes that may affect the completion date of the project.
2. Meetings with owners of operations. The project manager talks individually with the owner of each operation in order to get a real picture of the timing of its implementation. It is recommended to ask the following questions [18]:
Step 2 can be skipped if there is an established system for collecting real information on the progress of the project.
1. Conduct a meeting on the progress of the project. Meetings should be held regularly (once a month or once a week, depending on the duration of the project).
2. Registration of the protocol, which records the answers to the above questions, which are repeatedly asked to the owners of the operations in the framework of the meeting.
Fig. 7.5. Example of the project execution line (adapted from [18])
1. Drawing the line of execution.
Thus, the line of execution allows you to regularly monitor and adjust the implementation of the basic schedule of the project.
Chart of control events
The main difference from the execution line is that the diagram focuses on project control events.
For its drawing, the same steps are performed as in the construction of the line of execution, with one difference - the object of analysis are control events.
Fig. 7.6. Sample control event prediction chart
Construction of control events chart
На вертикальной оси отмечают даты наступления контрольных событий, зафиксированных в базовом расписании, - запланированные события.
На горизонтальной оси отмечают те же даты наступления контрольных событий.
Рисуют запланированную линию исполнения проекта, она проходит под углом в 45 градусов к каждой из осей. На линии исполнения отмечают запланированные контрольные события (см. рис. 7.6).
На совещании владелец первого контрольного события оценивает ход продвижения (выполнение операций, обеспечивающих достижение контрольного события) и фиксирует его на диаграмме, а также оценивает текущие проблемы, вызывающие отклонения от базового расписания, прогнозирует даты наступления контрольного события, определяет степень влияния фактических отклонений на зависимые контрольные события.
Graphically presented information on the progress of the project provides a visual representation of the internal dynamics of the project.
Comments
To leave a comment
software project management
Terms: software project management