Activity list – why is that?

3 min.

Summary

After work package planning has been completed, the activity list is created as a table. It is the following method to be applied according to the work breakdown structure. The activity list is the link between the work breakdown structure and the schedule.
The real added value is the task list, as a means of reducing the project duration, in that the core team with its expertise and the project manager identifies as many logical sequences as possible that can contribute to reducing the project duration. Even in an agile environment, dependencies need to be identified and taken into account. Splitting user stories without creating additional dependencies is an important skill of the SCRUM team.

What is the task list?

After completion of the work package planning, the process list is created. It is a table of all work packages and contains essential information from the work package planning from which the scheduling is derived in the further course.

The work breakdown structure (WBS) does not yet have any information on the functional sequence (“technical” dependencies). The activity list helps here. In project management, it is a “bridge medium” between WBS and the schedule. The activity list is a table of activities in the project. Based on the activity list, the project manager can determine the start and end dates of the work packages.

What is the added value of the activity list?

After creating the task list, it can be estimated for the first time whether it is possible to achieve the project goal within the framework of the available resources. Now it is possible to add all costs and capacities that were considered necessary by the WP managers. However, it is not yet possible to draw conclusions about the sufficient availability of the necessary capacities, since normally there is no uniform utilization, but rather individual capacity peaks represent the problem. It is also possible to record which predecessors are necessary to start a work package.

The real added value is the task list, as a means of reducing the project duration, in which the core team with its expertise and the project manager identifies as many logical sequences as possible that can contribute to reducing the project duration. So a lazy use of the end-start sequence, because this is so convenient and easy to do, would cost the client project time and drive up project costs. Alternative sequences such as Beginning-Start help the project manager reduce the number of tasks on the critical path. This simplifies project control. The work package managers should not define the inputs for the sequence relationship in a quiet chamber, but communicate them to the core team (sub-project manager or project manager in the program), which then determines optimized sequences. The creation and discussion of the process list thus raises the potential for later optimization of the flow and schedule at an early stage.

Differentiation / forerunner to the schedule

From the sequence of the work packages it can be derived when which work package starts. Work packages that do not have a direct predecessor can start immediately. All others follow. An initial schedule can be derived from this. This, however, is not much more than an indication, since diverse framework conditions such as staff vacation, capacity limits of few available qualifications are not taken into account.

What is the task list in an agile environment?

Even in an agile environment, dependencies need to be identified and taken into account. Here, for example, SCRUM teams already take into account how dependencies between backlog items are represented in the overall backlog planning. The split of the backlog items can be done initially by the product owner, but should be validated by the entire agile team lastest during the initial sprint planning. Even within SCRUM teams, dependencies are constantly re-evaluated, since the continuous prioritization of user stories can possibly lead to additional identified dependencies. Splitting user stories without creating additional dependencies is an important skill of the SCRUM team. However, it should be taken into account that the user stories are not only split according to the technical paths, but that the functional questions are also taken into account. Otherwise, the agile approach will be counteracted. Because then an early and small-scale delivery of functions is no longer guaranteed. As already mentioned, this balancing act of splitting up is a core competence of the entire team.

Agile vortex?!

3 min.

Summary

Agile work or delivery is only possible if necessary decisions can always be called up. It also does not work without appropriate governance. There is huge similarity in turnaround situations of classical projects with the approach of agile projects. The focus here is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. Agile principles will continue to spread differently in different industries. But whoever thinks of agility about method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results.

Agile project management does not work without appropriate governance

Agile work or delivery is only possible if necessary decisions can always be called up. In my article “Communication Principles in a Project” it is easy to see that the short time until a decision is made is extremely important. This is often slowed down or even blocked by the middle layers of management in a company. This so-called permafrost cannot comprehend the need for agility often sensibly identified by top management. Likewise, decisions necessary in the course of the project cannot be made by the senior management themselves, as are not be placed correctly with them.

Agile project management is very similar to the approach of classic projects in turnaround situations

In both cases, the focus is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. The classic project plan is then usually only a reference for contract-relevant delivery items. The chain of failure in projects is the customer relationship and thus the governance structure, then the tools and processes and at the latest the employee frustration. When introducing agile principles, the sequence is exactly the other way around. In my experience, the team atmosphere in project organizations can indicate a wide variety of problems at any time, and not only that “something” is wrong, but also in which project management domains (see my article SmileyPoints). It would also be interesting to use this method when introducing agile project management.

How will the agile vortex spread now?

As can be deduced from my article “Project Manager in 2030“, the agile principles will continue to spread differently in different industries. What this “agility” will look like, whether pure SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS, Spotify will be shaped by the customer and company environment (i.e. products, services, industry, size, etc.). Is “classic project management” dead? Certainly not, because there are certain complex (very large programs) and complicated (repetitive projects) for which classical project management will be the better alternative. Nevertheless, it makes sense for the classic project manager to make tool picking out of the agile box. But whoever associates agility with method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results. Concepts and planning are required in both approaches. Approaches such as scaled agile approaches e.g. SAFe take this aspect particularly into account.

The challenges for product owners or project managers

The challenge for the drivers of ventures, whether product owner, project manager or program manager, will now be that they should play different instruments in different environments. Because the dogmatic orientation “we only do agile single projects” can only take place in companies that have no need for diverse interfaces and environments. The exclusive product owner or program manager will therefore rather remain the rare species. A stigmatization of the two approaches is therefore certainly not meaningful, but the combined application or simply said the agile classical project is the future. Early and constant results and close end customer coordination are the success factor in all projects.