Projects are more than just frameworks – Part 2

In the 1st part of Projects are more than just frameworks you have already learned that projects need good structures and low dependencies to be successful and how team dynamics affect project progress. In part 2 you will learn more about methods, how to estimate the effort and how psychology can influence projects.

3. Methodological limitations that exist in every model

A particularly exciting and interesting read is "12 half-truths about IT projects" by Gerhard Friedrich, who uncovers methodological fallacies for both agile and waterfall projects and refutes them with examples from his project experience.

For reasons of time and space, I want to single out two of these 12 half-truths, which have represented particularly large effort multipliers in my projects so far:

1. Half-truth: Detailed requirement definition leads to reliable effort estimates

No sooner had the specifications and concepts of the conventional projects been converted into user stories by the Agile Manifesto in 'Working Product over Comprehensive Documentation' than there was an urge to divide these user stories into epics for implementation.
In my large project based on the SAFe approach, the epic descriptions and maintenance in Jira for effort estimates and work distribution are so degenerate that

• connections became increasingly unclear
• Epics were less maintained
• the effort involved was many times higher than the actual implementation.

2. Half-truth: Project controlling leads to more control

Or affectionately taken up with a management maxim "you get what you measure" leads to many (sometimes elaborately detailed) evaluations. This new focus on KPIs indirectly introduces project (re)prioritisation, which can be contradictory to the actual project goal.

For example, the project budget is tracked across portfolios. But even if everything is 'green' there, the actual progress and quality can still be poor and the project risks can seem unbearable. In the event of deviations, the reporting only shows symptoms.
Measures to eliminate the underlying causes should be taken after careful analysis. They cost additional effort and there is a time lag before the measures finally take effect.

My advice: Here, too, it is best to compare the evaluation effort with the benefit and project goal.

4. Psychological effects

In addition to the team dynamics and half-truths of methods, the psychological effects of each individual can also have a strong impact on a project. With his two books "The Art of Thinking Clearly: 52 Mistakes in Thinking That You're Better to Leave to Others" and "The Art of Clever Action: 52 Wrong Paths That You're Better to Leave to Others", Rolf Dobelli has shown numerous of these effects:

In 2016, these two books were presented by two it-economics colleagues. Since then, the effects described there have been reflected in the acceptance of requirements, estimates and in group dynamics. As part of a team, each of us can contribute to greater success in the project by recognizing these effects through self-reflection and consciously counteracting them.

To give an example of authority bias, in English: only those who have authority are right.
This can be a steering committee, program managers or product owners/scrum masters who estimate the effort for an IT solution Top-Down to pretend There are often very experienced employees in the teams, who could give more realistic estimates of effort due to their experience and proximity to the team and system.
In such a case one could use methodologies such as planning poker for Bottom-Up-Use estimates or empirical values ​​from similar projects. Admittedly, a bottom-up estimate initially takes much longer than a top-down estimate, but on the one hand it is more realistic and on the other hand it involves team commitment.

In the long term, realistic plans lead to more clarity and fewer misunderstandings, the need for coordination in the project itself and thus to a greater chance of project success and happier project employees.

To circumvent the authority bias,

• each individual can compare the specifications with their experience;
• Project Manager/Scrum Master establish bottom-up methodologies;
• Investors question who made the estimate or conception. Were subject-specific experts who can later work in the team asked? Have they implemented similar reference projects? Do they know the project environment well enough to be able to make a realistic estimate?

New projects that are started via a tendering process with a focus on costs are usually subject to unrealistic plans at the beginning and it is particularly important to pay attention to the authority bias there.
If the estimate of effort increases significantly after the call for tenders because you gain experience and include the estimates of the project workers, it is important that a realistic plan is established as quickly as possible. A project that is not ready to establish realistic plans is a project that is not yet ready to learn. However, unrealistic plans slow down project progress. The best-known example is probably the BER airport construction.

As a conclusion, everyone can take away that the heavily discussed frameworks are only part of a project. The corporate structures and project dependencies, the recognition of methodological limits and the psychological effects of each individual and the group are fundamental. This makes projects a complex system, but if you take it into account, it brings the project and thus the company's success much closer.

author

Julia Radick
Managing Consultant