In the entry from June 19, Łukasz showed in a very clear way that how to choose a project lifecycle. This choice determines what methods we will use to manage individual knowledge areas in project management.
Today I would like to take a look at the agility of PMBOK in the area of schedule management.
Wśród trendów i nowych praktyk, jakie pojawiają się w zarządzaniu harmonogramem, wydanie 6 PMBOKa zatrzymuje się nieco dłużej rzy dwóch z nich, tj. iteracyjnym harmonogramowaniem z backlogiem (iterative scheduling with a backlog) oraz harmonogramowaniem na żądanie (on-demand scheduling). Dla osób, które żyją w świecie zwinnego project management proces, nie będą to tematy nowe, jednak na uwagę zasługuje fakt, że praktyki te zostały zauważone, uznane za dobre, a zatem warte propagowania. Stały się standardami, zgodnie z którymi warto postępować, by osiągnąć sukces w zarządzaniu projektami.
Let's start with on-demand scheduling, whose roots date back to the 1950s, because it is usually used in the KANBAN system, is based on the theory of constraints and is an integral part of lean manufacturing. On-demand scheduling is not actually a schedule management system created in the early phase of a project in order to achieve product growth, but rather involves selecting from the product backlog or task queue those works that can be performed as soon as the necessary resources become available. A very important rule that must not be forgotten when using on-demand scheduling is to set a limit for work in progress. The great advantage of this method is transparency, because thanks to the KANBAN board, each team member knows what work is in progress, what has been completed, what is waiting in the queue and who is doing what at a given moment. Any bottlenecks are immediately visible. It is also worth remembering why KANBAN was discovered. The easiest way to understand this is to learn the slogan "7 x none":
- no deficiencies,
- no delays,
- no supplies,
- no queues – anywhere and for anything,
- no idleness,
- no unnecessary technological and control operations,
- no displacements.
Therefore, the point is for everyone to do what and only what is most important at a given moment, for no one to wait for anything, and to do every job with the least possible effort.
The second schedule management method is iterative scheduling with a backlog. It is a type of rolling planning based on adaptive life cycles. In the agile approach to product development, requirements are written in the form of user stories. They are then prioritized and refined immediately before work begins. A characteristic feature of this method is that individual stories are transformed into an increase in the value of the product, in precisely defined time intervals, called sprints or iterations, the length of which usually ranges from 1 to 4 weeks. The time required to deliver individual functionalities described in user stories is usually expressed in hours or so-called story points that show the relative complexity of a given job in relation to other jobs. In other words, using story points, we estimate how much larger (more labor-intensive) one story is than the other. Typically, only certain numbers are used when estimating stories. The two most popular scales are the exponential scale (1, 2, 4, 8, 16,…), often used in XP, and the Fibonacci sequence (1, 2, 3, 5, 8, 13…) usually used by Scrum teams. Planning Poker was created based on the Fibonacci sequence, a very popular game in which members of agile teams use cards with the numbers 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 100.
A very important feature of this method is that the iteration ends when the designated time elapses, regardless of whether all planned work has been completed or not. After each iteration, the work is summarized, the results are presented, changes are made to the backlog if necessary, and an analysis of things that can be done to improve the team's work and the value of subsequent work.
Both methods mentioned above can also be successfully used in projects that are not agile in nature, but find themselves in a specific situation - e.g. when the project is delayed or there is a need to speed up work, you can successfully use the KANBAN board to divide larger activities into smaller tasks and assigning specific team members to them. You can also isolate what is most important to the client from the entire scope of the project, adopt a rhythm of short periods after which we present results and collect feedback, or finally adopt daily briefings and work summaries.
Each project has its own rhythm, and it is rarely monotonous. In this respect, the work of a project manager actually resembles that of a conductor who knows what instruments should be played to achieve harmony.
In the next episode, I would like to discuss alternative methods of creating, presenting and controlling the project schedule.
Author: Arkadiusz Urbański
