When an IT project starts to go off the rails, it’s usually preceded by several weeks of unnoticed warning signs. The meeting in which it becomes clear that the go-live date can’t be met feels like the beginning of the crisis. In reality, it’s just the moment when the crisis becomes visible.
During the first 14 days of an IT project crisis, diagnosis takes precedence over hasty action. Days 1 through 3 are for the situation picture of roles, risks and blockers; days 4 to 7 for the stakeholders and the contract; days 8 to 11 for the in-depth technical review; days 12 to 14 for the reasoned decision: continue, rebuild or stop.
What Matters in the First Few Days of an IT Project Crisis
The question of what to do usually comes up too soon. First, we need to clarify what we actually know at that moment and what we only think we know. That is precisely why rushing into action isn’t helpful in the early days. Traditional crisis project management first focuses on establishing a clear picture of the situation before even considering shifting milestones or reallocating resources (Projekt Magazin, 2015). Those who immediately push back deadlines without knowing the cause are often just postponing the next failure by a few weeks.
The First 14 Days as a Decision Tree
An approach that has proven effective in practice divides the first two weeks into four phases, each with its own goal. It is not a rigid formula, but a framework that prevents the crisis from becoming a never-ending issue instead of leading to a decision.
| Time period | Phase | Key Question | Result |
|---|---|---|---|
| Days 1 through 3 | Situation Report | Who decides, and which risks are documented | Written overview of roles, risks, and obstacles |
| Days 4 through 7 | Stakeholders and Contract | What Has Been Agreed Upon, What Is Expected | Aligning the Contract with Expectations |
| Days 8 through 11 | In-Depth Technical Review | Does the foundation support it? | Findings on Code, Architecture, and Data |
| Days 12 through 14 | Decision | Continue working, make changes, or stop | recommendation supported by a written explanation |
- Days 1 through 3, Situation Report. Who actually makes decisions in this project, and who merely thinks they do? Which risks are documented, and which are merely the subject of office gossip? The goal of this phase is to establish a reliable, written overview of roles, risks, and outstanding obstacles—not to assign blame or make judgments. Deutscher Consulting describes precisely this approach as the standard for the first ten days of an engagement (Deutscher Consulting, 2025).
- Days 4 through 7: Stakeholders and Contract. Next come discussions with the client, the department, and, if involved, the external service provider. What does the contract say about acceptance criteria and change processes? Where do the verbal expectations differ from what was agreed upon in writing? This phase often reveals more than the technical analysis, because it shows whether there is any agreement at all on what the project is supposed to deliver.
- Days 8 to 11, in-depth technical review. Only now do we take a closer look at the code, architecture, and data model. How high is the test coverage? How thoroughly are the interfaces documented? How many workarounds are hidden in the system that no one can explain anymore? This phase determines whether the technical foundation is sound or whether it is the actual cause of the delay.
- Days 12 through 14: The Decision. Based on the three preceding phases, one of three recommendations is made: continue working with an adjusted plan, restructure the project technically or organizationally, or halt it and start over. This decision must be justified in writing, supported by specific observations as evidence, rather than based on the responsible person’s gut feeling.
Why Order Matters
The most common mistake in practice lies in the order of steps at the beginning. Those who begin with the technical review before the scope of roles and expectations has been established often end up evaluating the wrong system because it is unclear what the system is actually supposed to achieve. Those who, instead, immediately discuss contracts with stakeholders before there is internal clarity on risks are negotiating from a position of weakness.
According to this model, operational stability—that is, a state in which the IT project is once again running according to plan and can be effectively managed—is not achieved until Day 30 (Deutscher Consulting, 2025). The first two weeks provide the basis for decision-making. Implementation then takes just as long, and often even longer.
For the patterns featured in the article Why IT Projects Fail As described above, this is especially true, because unclear requirements cannot be clarified on the side.
Get a snapshot of the situation in two weeks without tying up your team's timeWe’ll conduct the review and provide a written recommendation with supporting rationale. If the project is viable, we’ll say so.
What exactly will be the outcome at the end of the 14 days?
The three possible outcomes differ greatly in terms of effort and risk. Continuing to work with an adjusted plan usually means setting new milestones, revising reports to senior management, and often reducing the scope of functionality to what is truly necessary by the original deadline. In practice, restructuring often involves the architecture or the team structure—for example, when two groups are working on the same module in parallel without anyone taking responsibility for the interface. Halting the project is the rarest but most important option if the in-depth technical review reveals that the foundation is not sound.
A fresh start may sound like the biggest loss, but it is sometimes the more cost-effective option compared to an IT project that continues to burn through money for months on end without getting any closer to the goal. The criteria for this are outlined in the article on Save the Project or Start Over.
It is important to note that this decision does not rest solely with the person who conducted the 14-day review. That review provides the factual basis. The decision itself should be made at the level responsible for the budget—usually executive management or IT leadership, in collaboration with the project sponsor.
Frequently Asked Questions
Who conducts the analysis during the first 14 days?
Ideally, someone with technical and organizational experience who was not part of the project structure up to this point. Internal decision-makers are often too closely tied to past decisions to evaluate them impartially. A Interim CTO often takes on this role for exactly the duration of the review and beyond.
Should the team keep working during the review?
Generally speaking, yes—for uncontroversial parts of the system where halting development would only result in additional costs without yielding any new insights. For areas directly affected by the decision—such as a controversial architectural component—it is worth temporarily halting development until the in-depth review is complete.
What do you tell the team at this stage?
Transparency about the process inspires more confidence than reassurances. A team that knows a structured review is underway with a fixed timeline and knows when a decision will be made works with greater focus than one that only hears rumors about a possible realignment.
The Next Step
torck conducts the situation analysis, stakeholder assessment, and technical review as a team, which then continues the development work itself rather than simply submitting a report. Once a decision has been made, in-house development teams in Maxhütte-Haidhof, Vienna, and Rabat are ready to immediately take over implementation and technical leadership. Schedule a no-obligation initial consultation for your specific project situation.
German 
English 
French