When an IT project hits a snag, the knee-jerk reaction in many organizations is surprisingly similar: they bring in more people. Another developer, a second consultant, a third freelancer to “lend a hand.” The assumption behind this is intuitive: more hands mean more work gets done. In practice, however, this equation rarely holds true. Delays rarely occur because too few people are working on the project. They arise because it is unclear exactly what needs to be done, who decides that, and whether what is reported to upper management still has anything to do with the reality on the ground.
This became particularly clear in a project for a public sector client. The goal was to develop a modern desktop for public administration in accordance with the German Administration Cloud Strategy (in German: Deutsche Verwaltungscloud-Strategie, short DVS). A previously monolithic software platform was to be containerized and made scalable…as an MVP, within a fixed timeframe of nine months. The project was staffed primarily with freelancers. When we joined, the project was at least a year behind schedule; key components had not been containerized, and modules that needed to be developed from scratch did not exist at all or, at best, existed only as proof of concept.
“Everything was green,” even though nothing was working
Perhaps the most striking finding was not a technical one. Project management consistently reported “everything’s fine” to upper management, while in the engine room, hardly any progress was being made. This gap between status reports and reality is more dangerous than any individual technical issue. For as long as upper management is under the impression that everything is going according to plan, they will do exactly what exacerbates the situation: wait it out, persevere, and, when in doubt, allocate even more resources.
On top of that: No meaningful processes had been established or followed within the team. There was no binding procedure, no reliable deliverables, and no authority to consolidate requirements and make decisions. And some of the hired external consultants lacked the necessary skills and were also unwilling to familiarize themselves with the work. Under these conditions, every additional person did not increase delivery capacity, but rather the number of touchpoints where the same unresolved questions were reinterpreted.
Hiring more external staff is not the solution to a structural problem
External resources are highly effective at solving specific problems: when the task is clear, the requirements are stable, and the only thing missing is the capacity to execute, additional manpower does indeed speed things up. However, these exact conditions are almost never met in projects that have stalled.
In this project, the scope was unclear, processes were missing, and some of the personnel involved were unable or unwilling to fill the gap. What looked like a capacity problem was, in reality, a management problem. And management problems cannot be solved with resources. They are actually exacerbated by additional resources: more participants mean more coordination, more assumptions, and more variations on the same unclear directive.
Transparency first, speed Second: Realigning Project Management
This is where the realignment began. Instead of adding more resources, we first restructured the project management and established transparency regarding where the project actually stood, not where it was supposed to be according to the reports.
Specifically, this meant: We introduced Scrum and ensured that the processes were actually followed and that the necessary artifacts existed. We established close communication between development and product management to clearly define the requirements for the MVP and — just as importantly — to deliberately limit the scope. We evaluated the performance of the external contractors and made adjustments where the necessary skill set was lacking: through targeted hiring rather than simply increasing headcount. We scrutinized the technology concepts provided and had them refined rather than adopting them unchecked. And on this basis, we had a new, robust schedule drawn up.
These steps sound formal, almost like additional overhead. In fact, they immediately relieved the project. The key side effect: by decoupling the processes between internal developers and external service providers, we took the pressure off both sides. Everyone knew where they stood again and could spend their time on content rather than on endless coordination loops.
Adjusting course instead of persisting
A second step, at least as important, was the willingness not to simply let the project run its course. In many organizations, there is an implicit expectation that once a project has been launched, it will be carried through, preferably without any visible adjustments. Delays are absorbed, resources are increased, scopes are quietly shifted, but the original plan remains untouched. In the worst case, even the “green” status remains unchanged.
This attitude costs more than it is meant to prevent. Those who persevere without making adjustments accept that the gap between plan and reality will keep growing until it can no longer be closed. Making adjustments, on the other hand, means consciously reviewing and adapting assumptions, scope, and approach at defined points in time, and honestly identifying what is actually achievable with the available resources and time. That is exactly what we did: we focused the scope on a deliverable MVP and assembled the team so that it could actually achieve that. Course correction is not an admission of error, but an expression of professional project management.
The impact of clear management decisions
The impact of these decisions was measurable. The project, which had fallen at least a year behind schedule, was completed on time nine months later, and the product was delivered. What had been a crisis-ridden endeavor was transformed back into a manageable project.
Just as important was the lasting impact. Stable structures were established for future development. From the outset, the product was designed to be usable not only within this project but also for other external clients. Since then, the client has been perceived as capable of delivering, responsive, and reliable. This has resulted in recurring revenue and concrete growth opportunities. A project that was on the verge of failure thus became a foundation for the business.
These effects are no coincidence. They are the predictable result when management is understood and exercised as an independent leadership task, rather than treated as a byproduct of implementation.
Resources: Reinforcing what already exists
External resources are a valuable tool. However, they serve to reinforce what is already in place. In well-managed projects, they enhance delivery capabilities. In poorly managed projects, they exacerbate confusion. Anyone who, in a crisis situation, immediately turns to hiring additional staff without first addressing the management issues is only accelerating the actual problem.
This is exactly where flowciety comes in. We help companies answer the more important questions before asking for more resources: Who decides on requirements? Which requirements actually apply? How is what is actually happening in the project honestly tracked? Only when these fundamentals are in place do external partners deliver the impact expected of them.
In our white paper on IT architecture, we demonstrate how clear roles, a limited, resilient scope, and defined decision-making processes stabilize projects before additional resources are brought into play.
Source of cover image: emwe studio
We are IT partners
Our motto: Establish IT in everyday business as a solution, not as a source of problems.
