Projekte werden umso komplexer je abstrakter der Projektgegenstand wird. Vor allem IT Projekte haben oft eine sehr abstrakte Zielsetzung, die zu Beginn des Projekts niemals detailliert genug festgeschrieben werden kann. Erst im Verlauf der Projektarbeiten lernt man zu verstehen, was da eigentlich entsteht. Im Prinzip funktioniert ein Projekt so, dass man die Tasks abarbeitet, die man erkennt. Ist die Arbeit getan, kann man die Tasks von der Liste, der noch zu erledigenden Tasks, streichen. Während man aber arbeitet, gewinnt man neue Erkenntnisse. Das Wissen über den Projektgegenstand nimmt zu. Mit jeder Erkenntnis sieht man aber wieder neue Tasks, die man auf die Liste schreibt. Nun haben wir also zwei Feedbacks: Je mehr Tasks, desto mehr Arbeit, desto mehr Tasks kann man schliessen (also desto weniger offene Tasks sind vorhanden - daher das “-” beim Pfeil in Loop A, der von der Work in Progress nach Tasks to do zeigt). Und Je mehr Arbeit, desto mehr Erkenntnisse, desto mehr Tasks (Loop B).

Das Wissen nimmt im Verlauf des Projekts zu, erreicht ein Maximum und nimmt dann wieder ab. Das hat verschiedene Gründe. Erstens interessieren viele Dinge bald einfach nicht mehr, weil man sie so gut verstanden hat, dass sie selbstverständlich werden. Weiter vergisst man schlichtweg auch zahlreiche Einsichten, die man hatte, so wie man Namen vergisst. Diesem Verhalten des Wissens folgt das Verhalten der Anzahl Tasks, die noch zu erledigen sind. Auch sie nehmen - Gott sei Dank - mal ab. Allerdings oszilliert diese Task- und Issuelist aufgrund von Verzögerungen, die den beiden Feedbackloops inhärent sind. Man kann also damit rechnen, dass die Anzahl Tasks wieder leicht ansteigen wird, nachdem sie in der zweiten Hälfte des Projekts den Anschein machten, abzunehmen.