# Go Projects

> How software projects succeed: requirements, estimates, budget, agile or classic planning, risks and the most common reasons projects fail.

- [How to Plan a Software Project: 7 Steps Before Kick-off](https://go-projects.de/en/planning/plan-a-software-project/): 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/): 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/): 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/): 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/): 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/): 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/): 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/): 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/): 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/): 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/): 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/): 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.

About this site: https://go-projects.de/en/about/