IT Projects & Technical Due Diligence
Project documentation is heterogeneous: tickets, minutes, architecture decision records, repository history and operational records can each describe a different layer of the same project. A technical reconstruction classifies these sources, anchors them in time and tests whether claimed decisions are reflected in the implemented system.
Short answer
A document that states a decision was made does not automatically establish when the corresponding technical change occurred. Conversely, a code change can exist without a surviving decision record.
Contradictions and missing records are findings about traceability. They should not be smoothed into a coherent story unless the available evidence supports that reconciliation.
1. Distinguish project sources by evidence type
Different documents support different propositions
A ticket can describe a request or discussion, meeting minutes can record a stated decision, an ADR can document architecture rationale, and a commit can record a versioned technical change. These sources should not be treated as interchangeable.
The examination records provenance, authoring context and revision history where available. A later export may preserve only the current state of a record and omit earlier changes.
Source classification helps a reviewer understand whether a conclusion rests on direct technical evidence, project documentation or later explanatory statements.
2. Build chronology from defensible time anchors
Document dates can refer to different events
A meeting date, file creation time, last-modified time, ticket transition and commit timestamp each describe a different event. The reconstruction identifies which semantic meaning is relevant before placing the value on a chronology.
Where documents have version history, that history can reveal whether a statement existed contemporaneously or was added later. Without such history, a current document should not automatically be treated as proof of its earlier content.
Time anchors can be stronger when they correlate with technical systems such as repository commits, build records or deployment logs.
3. Connect decision claims to technical implementation
A stated decision and an implemented change are separate steps
When documentation claims that a technology, interface or architecture was changed, the examination looks for corresponding code, configuration, dependency or deployment changes.
A technical implementation can precede or follow the document that describes it. The report preserves this relationship rather than assuming the document date is the implementation date.
Where no direct technical evidence remains, the reconstruction can state that the claimed decision is documented but its implementation is not independently verified.
4. Do not smooth contradictions into one narrative
Conflicting records may reveal a changing or disputed project state
Tickets, minutes and repositories can disagree about dates, intended scope or status. The examination presents those conflicts and tests whether version history, technical artefacts or later events resolve them.
Conflicts should not automatically be labelled errors. A project can legitimately revise a decision. The key is whether the sources allow that revision to be reconstructed.
Where two plausible readings remain, both can be reported with the evidence supporting each.
5. Treat documentation gaps as findings about traceability
Missing records are not proof of poor project management
Missing ADRs, deleted tickets or absent meeting minutes limit the reconstruction but do not automatically prove that no decision was made or that project governance was defective.
The technical finding is that the examined evidence does not contain a sufficiently direct record for the asserted decision. This is different from stating that the decision did not exist.
Gaps can become material when they prevent version, responsibility or system-state assignments needed for the examination question.
6. Limit reconstruction to the examination question
A project archive can contain far more material than the technical issue requires
Source selection should follow the concrete question rather than attempt to retell the entire project. Relevant systems, decisions, time period and artefact classes are defined at the outset.
A focused chronology can still include counterevidence when it challenges the leading interpretation. Scope is not a reason to ignore contradictory material directly relevant to the question.
The final result separates technical reconstruction from organisational, commercial or legal assessment of the decision-making process.
Is the reconstructed decision history traceable to source type, time and implementation?
- Are project records classified by source type and provenance?
- Are creation, modification, approval and technical implementation dates distinguished?
- Are later document versions prevented from being projected backwards without evidence?
- Are documented decisions linked to code, configuration or deployment changes where possible?
- Are contradictions preserved and tested rather than narratively removed?
- Are missing records treated as traceability limits rather than proof of absence?
- Is the selected source scope tied to the concrete examination question?
- Are technical reconstruction and organisational or legal evaluation separated?
Constructed example
An ADR states that the project moved from one database technology to another. Repository and deployment evidence show the dependency change two weeks later, while meeting minutes suggest the decision had been discussed earlier.
The reconstruction can distinguish the documented discussion date, ADR date and implementation date. If no earlier ADR version exists, it does not retroactively assign the final wording to the earlier meeting.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Technical primary source Git documentation: git-log, used for examination of commit histories. Open source.
- Technical primary source Git revision syntax, used for unambiguous reference to development states. Open source.
- Author methodology Sources and Methodology of the German knowledge base. Open source.
Further reading
- Reconstructing the History of an IT Project
- Reconstructing Architecture Decisions and Technical Risks
- Reconstructing Change Requests and Change States
- Requirements, Actual State and Technical Acceptance
Critical review and methodological limitation
Documentation quality and technical truth are not the same thing. Missing documentation limits traceability, while technical artefacts may still establish parts of the project history.
Conversely, well-written documentation does not prove that the described implementation or decision existed at the stated time.
- Source class: statements, technical artefacts and later explanations carry different evidentiary roles.
- Time: document date and implementation date should not be merged.
- Gap: absence of a record limits reconstruction but does not automatically prove absence of the underlying decision.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Project Assessments & Project Reconstruction
Traceable reconstruction of requirements, change states, repositories, releases, technical decisions and project risks.
Explore this assessment service