# Go Projects

> Wie Softwareprojekte gelingen: Lastenheft und Pflichtenheft, Schätzung, Budget, agile oder klassische Planung, Risiken und die häufigsten Gründe für das Scheitern.

Go Projects ist ein zweisprachiger Ratgeber (Deutsch/Englisch) der OnlineBuilders LLC (https://onlinebuilders.biz/), eines US-Technologie-Studios für SaaS, KI und Datenplattformen. Jede Seite gibt es auch als Markdown: an die URL `index.md` anhängen. Die Links unten zeigen direkt auf die Markdown-Fassungen.

## Planung

- [Softwareprojekt planen: die 7 Schritte vor dem Kick-off](https://go-projects.de/projektplanung/softwareprojekt-planen/index.md): Ein Softwareprojekt planst du in sieben Schritten: Ziel und Erfolgskriterium festlegen, Nutzer und Anforderungen sammeln, den Umfang priorisieren, Aufwand als Spanne schätzen, Vorgehen und Rollen bestimmen, Risiken benennen und einen Meilensteinplan mit festen Prüfpunkten aufsetzen. Erst danach lohnt sich Code. Der Plan wird nach jedem Meilenstein aktualisiert, nicht einmal geschrieben und abgeheftet.
- [Lastenheft Software: Vorlage mit Gliederung und Beispielen](https://go-projects.de/projektplanung/lastenheft-software-vorlage/index.md): Ein Lastenheft für Software beschreibt aus Sicht des Auftraggebers, was die Software leisten soll, nicht wie sie gebaut wird. Eine brauchbare Vorlage enthält Ausgangslage, Ziele, Nutzergruppen, funktionale und nicht-funktionale Anforderungen, Schnittstellen, Rahmenbedingungen, Abnahmekriterien und eine Abgrenzung dessen, was nicht dazugehört. Der Auftragnehmer antwortet darauf mit dem Pflichtenheft.
- [User Stories schreiben: Vorlage, Beispiele, Kriterien](https://go-projects.de/projektplanung/user-stories-schreiben/index.md): Eine User Story schreibst du nach dem Muster „Als [Rolle] möchte ich [Ziel], damit [Nutzen]“ und ergänzt sie um drei bis sieben Akzeptanzkriterien, die ein Tester abhaken kann. Gute Stories erfüllen die INVEST-Kriterien: unabhängig, verhandelbar, wertvoll, schätzbar, klein und testbar. Zu große Stories zerlegst du entlang von Arbeitsschritten, Regeln oder Datenvarianten.
- [MoSCoW-Priorisierung: Anforderungen richtig einteilen](https://go-projects.de/projektplanung/moscow-priorisierung/index.md): Bei der MoSCoW-Priorisierung teilst du Anforderungen in vier Gruppen: Must have (ohne geht es nicht live), Should have (wichtig, aber verschiebbar), Could have (wünschenswert) und Won't have this time (bewusst nicht jetzt). Entscheidend ist die Budgetregel: Muss-Anforderungen sollten höchstens 60 Prozent des geschätzten Aufwands ausmachen, damit Reserve für Unvorhergesehenes bleibt.

## Schätzung & Budget

- [Software entwickeln lassen: Kosten realistisch kalkulieren](https://go-projects.de/schaetzung-und-budget/software-entwickeln-lassen-kosten/index.md): Die Kosten ergeben sich aus Aufwand mal Stundensatz. Freie Softwareentwickler in Deutschland verlangen im Median rund 90 Euro netto pro Stunde (freelancermap, September 2026), Agenturen meist mehr. Ein einfaches internes Tool mit 300 Stunden liegt damit bei etwa 27.000 Euro, eine Fachanwendung mit Schnittstellen schnell im sechsstelligen Bereich. Wartung und Weiterentwicklung kommen über die Laufzeit hinzu.
- [Aufwandsschätzung Software: Methoden und Rechenbeispiel](https://go-projects.de/schaetzung-und-budget/aufwandsschaetzung-software/index.md): Für eine belastbare Aufwandsschätzung zerlegst du das Projekt in Arbeitspakete, schätzt jedes mit optimistischem, wahrscheinlichem und pessimistischem Wert und rechnest nach PERT: (O + 4M + P) / 6. Die Summe ergänzt du um eine Streuung und kommunizierst das Ergebnis als Spanne mit Wahrscheinlichkeit, etwa „62 bis 72 Personentage, mit 80 Prozent unter 69“.
- [Story Points schätzen: Planning Poker und Velocity erklärt](https://go-projects.de/schaetzung-und-budget/story-points-schaetzen/index.md): Story Points schätzt du relativ, nicht in Stunden: Das Team wählt eine kleine, gut verstandene Referenz-Story als 2 oder 3 Punkte und vergleicht neue Stories damit. Beim Planning Poker legen alle verdeckt eine Fibonacci-Karte, große Abweichungen werden besprochen. Aus der Velocity vergangener Sprints ergibt sich dann eine Prognose als Spanne.
- [Festpreis oder Time and Material: welches Modell passt?](https://go-projects.de/schaetzung-und-budget/festpreis-oder-aufwand/index.md): Ein Festpreis lohnt sich, wenn der Umfang stabil und präzise beschrieben ist. Dann trägt der Anbieter das Kostenrisiko, preist es aber ein. Time and Material passt, wenn Anforderungen sich noch ändern werden. Du zahlst den tatsächlichen Aufwand und steuerst den Umfang selbst. Oft am besten: Abrechnung nach Aufwand mit Budgetdeckel und festem Umfang nur für Muss-Anforderungen.

## Steuerung

- [Agil vs. Wasserfall: Wann welches Vorgehen passt](https://go-projects.de/projektsteuerung/agil-vs-wasserfall/index.md): Wasserfall plant alle Phasen nacheinander und passt, wenn Anforderungen stabil, gut beschreibbar und vertraglich fixiert sein müssen. Agile Verfahren wie Scrum liefern in kurzen Zyklen von höchstens einem Monat lauffähige Teilergebnisse und passen, wenn Anforderungen sich erst durch Nutzung klären. Viele Projekte fahren am besten hybrid: Rahmen und Budget klassisch, Umsetzung agil.
- [Warum scheitern IT-Projekte? Ursachen und Frühwarnzeichen](https://go-projects.de/projektsteuerung/warum-it-projekte-scheitern/index.md): IT-Projekte scheitern meist nicht an der Technik, sondern an unklaren Zielen, schleichend wachsendem Umfang, Schätzungen, die zu Zusagen werden, fehlenden Entscheidern auf Fachseite und dem Unwillen, rechtzeitig abzubrechen. Große Studien zeigen außerdem: Gefährlich ist nicht die durchschnittliche Überschreitung, sondern der Ausreißer, bei dem sich Kosten verdreifachen.
- [Change Request im Projekt: Ablauf, Vorlage, Bewertung](https://go-projects.de/projektsteuerung/change-request-projekt/index.md): Ein Change Request ist ein formaler Antrag, den vereinbarten Projektumfang zu ändern. Er wird schriftlich gestellt, vom Auftragnehmer nach Aufwand, Kosten, Termin und Risiko bewertet und von einer benannten Person freigegeben oder abgelehnt. Erst nach Freigabe wird umgesetzt. So bleibt sichtbar, warum Budget und Termin sich verschieben.
- [Abnahmeprotokoll Software: Vorlage und Ablauf der Abnahme](https://go-projects.de/projektsteuerung/abnahme-software-abnahmeprotokoll/index.md): Ein Abnahmeprotokoll für Software hält fest, was getestet wurde, welche Mängel mit welcher Schwere gefunden wurden, ob abgenommen wird und welche Rechte sich der Auftraggeber vorbehält. Wichtig, weil die Abnahme nach § 640 BGB die Vergütung fällig macht und bei bekannten Mängeln ohne Vorbehalt Rechte verloren gehen können.

## English

- [How to Plan a Software Project: 7 Steps Before Kick-off](https://go-projects.de/en/planning/plan-a-software-project/index.md): To plan a software project, define one measurable goal, collect users and requirements, cut scope to the must-haves, estimate effort as a range, pick a delivery approach with named decision-makers, list the top risks, and set milestones that each end in a go or stop decision. Revisit the plan at every milestone instead of defending it.
- [Software Requirements Document Template (with Examples)](https://go-projects.de/en/planning/software-requirements-document-template/index.md): A software requirements document describes what the system must do and under which constraints, without prescribing how to build it. A usable template covers background, goals, users, functional and non-functional requirements, data and integrations, security, constraints, acceptance criteria, out-of-scope items and open questions. Each requirement should be testable with a clear yes or no.
- [How to Write User Stories: Template, Examples, Criteria](https://go-projects.de/en/planning/how-to-write-user-stories/index.md): Write a user story as "As a [role], I want [goal], so that [benefit]", then add three to seven acceptance criteria a tester can check with yes or no. Good stories pass the INVEST test: independent, negotiable, valuable, estimable, small and testable. Split stories that are too big along workflow steps, business rules, data variations or quality levels.
- [MoSCoW Prioritization: Rules, Example and the 60% Limit](https://go-projects.de/en/planning/moscow-prioritization/index.md): MoSCoW prioritization sorts requirements into must have (the release fails without it), should have (important but can wait), could have (nice to have) and won't have this time (deliberately deferred). The rule that makes it work: must-haves should take no more than 60 percent of the estimated effort, leaving contingency for surprises.
- [Custom Software Development Cost: A Realistic Budget](https://go-projects.de/en/estimates-and-budget/custom-software-development-cost/index.md): Custom software development cost equals estimated hours multiplied by the hourly rate, plus maintenance over the system's life. A 300-hour internal tool at $100 an hour costs about $30,000; an integrated business application can pass $200,000. Robert Glass puts maintenance at 40 to 80 percent of lifetime software cost, so budget for years of upkeep, not just the build.
- [Software Estimation Techniques: Methods and a PERT Example](https://go-projects.de/en/estimates-and-budget/software-estimation-techniques/index.md): The most practical software estimation technique for most teams is a bottom-up three-point estimate: break the work into packages, give each an optimistic, most likely and pessimistic value, and apply PERT, (O + 4M + P) / 6. Combine the spread across packages and report a range with a probability, such as 47 to 53 days, 80 percent under 51.
- [Story Points Estimation: Planning Poker and Velocity](https://go-projects.de/en/estimates-and-budget/story-points-estimation/index.md): Story points estimation is relative, not hourly. The team picks a small, well-understood reference story as 2 or 3 points and sizes new stories against it. In Planning Poker everyone reveals a Fibonacci card at once and outliers explain their view. Past sprint velocity then turns the remaining backlog into a forecast range.
- [Fixed Price vs Time and Materials: Which Contract Fits?](https://go-projects.de/en/estimates-and-budget/fixed-price-vs-time-and-materials/index.md): Choose a fixed price when scope is stable and precisely specified: the vendor carries the cost risk but charges a premium for it. Choose time and materials when requirements will evolve: you pay actual effort and control scope yourself. A common middle ground is time and materials with a not-to-exceed ceiling and committed must-have scope.
- [Agile vs Waterfall: How to Choose for Your Project](https://go-projects.de/en/running-the-project/agile-vs-waterfall/index.md): Waterfall runs phases in sequence and fits projects with stable requirements that can be specified and contracted up front. Agile methods such as Scrum deliver working increments in cycles of a month or less and suit projects whose requirements only become clear through use. Many projects do best with a hybrid: frame and budget first, delivery in sprints.
- [Why Software Projects Fail: Causes and Early Warning Signs](https://go-projects.de/en/running-the-project/why-software-projects-fail/index.md): Software projects rarely fail because of technology. They fail because of vague goals, scope that grows unnoticed, early estimates treated as commitments, missing business decision-makers and an unwillingness to stop in time. Large studies add a key insight: the average overrun is survivable, but roughly one project in six blows its budget by about 200 percent.
- [Change Request Process: Steps, Template and Impact Analysis](https://go-projects.de/en/running-the-project/change-request-process/index.md): A change request process turns any proposed change to agreed scope into a written request, has the delivery team assess effort, cost, schedule and risk, and lets a named person approve, reject or defer it. Work starts only after approval. That keeps every budget or deadline shift traceable to a decision someone made deliberately.
- [User Acceptance Testing Checklist: Plan, Run, Sign Off](https://go-projects.de/en/running-the-project/user-acceptance-testing-checklist/index.md): A user acceptance testing checklist confirms that entry criteria are met, real users test agreed scenarios with realistic data, every defect gets a severity and deadline, and a sign-off record states what was accepted, with which reservations. Prepare acceptance criteria before development starts, because UAT can only check what was agreed in writing.

## Optional

- [Full text](https://go-projects.de/llms-full.txt): Alle Artikel als Klartext
- [Sitemap](https://go-projects.de/sitemap.xml)
- [OnlineBuilders LLC](https://onlinebuilders.biz/llms.txt): Herausgeber