https://glossar.hs-augsburg.de/w/api.php?action=feedcontributions&feedformat=atom&user=Wilben 2026-07-19T17:45:29Z Benutzerbeiträge MediaWiki 1.43.3 https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9571 2007-06-21T11:18:50Z

<p>Wilben: </p> <hr /> <div>=Definition=<br /> Schätzungen werden frühzeitig in den ersten Projektphasen erstellt. Eine erste Schätzung sollte spätestens während der Definitionsphase erfolgen. Da bei einer Erstschätzung noch viele unbekannte Größen vorhanden sind, fällt diese meist nicht sehr genau aus und bedarf einer stetigen Korrektur im weiteren Projektverlauf. Auch wenn diese Schätzung ungenau ausfällt, ist diese aber vor allem für den Auftraggeber wichtig, da sie erstmals Aussagen über Kosten- und Zeitaufwand ermöglicht<br /> <br /> =Quellen=<br /> *[[Kowarschick, W. (2006): Skriptum zur Vorlesung Projektmanagement]]<br /> =Literatur=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Projektmanagement]]<br /> [[en:Category:Cost Estimatimation]]<br /> {{Quellenangaben fehlen}}</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9555 2007-06-20T11:44:31Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> =Einleitung=<br /> Aufwandschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> =Gründe für mangelhafte Schätzungen=<br /> Erfahrungen, welche mit ähnlichen Projekten gemacht wurden, werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würde oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um letztendlich den Zuschlag für ein Projekt zu bekommen .<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> =Fazit=<br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]<br /> [[Kategorie:Glossar]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9553 2007-06-20T04:14:12Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einen Erfahrungen, welche mit ähnlichen Projekten gemacht wurden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würde oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um letztendlich den Zuschlag für ein Projekt zu bekommen .<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]<br /> [[Kategorie:Glossar]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9545 2007-06-20T03:51:26Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einen Erfahrungen, welche mit ähnlichen Projekten gemacht wurden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würde oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können, um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]<br /> [[Kategorie:Glossar]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9542 2007-06-19T17:58:28Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]<br /> [[Kategorie:Glossar]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9539 2007-06-19T17:54:05Z

<p>Wilben: </p> <hr /> <div>[[Kategorie:Projektmanagement]]<br /> [[en:Category:Cost Estimate Project Management]]<br /> <br /> =Definition=<br /> Schätzungen werden frühzeitig in den ersten Projektphasen erstellt. Eine erste Schätzung sollte spätestens während der Definitionsphase erfolgen. Da bei einer Erstschätzung noch viele unbekannte Größen vorhanden sind, fällt diese meist nicht sehr genau aus und bedarf einer stetigen Korrektur im weiteren Projektverlauf. Auch wenn diese Schätzung ungenau ausfällt, ist diese aber vor allem für den Auftraggeber wichtig, da sie erstmals Aussagen über Kosten- und Zeitaufwand ermöglicht</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9538 2007-06-19T17:53:44Z

<p>Wilben: </p> <hr /> <div>[[Kategorie:Projektmanagement]]<br /> [[Kategorie:Glossar]]<br /> [[en:Category:Cost Estimate Project Management]]<br /> <br /> =Definition=<br /> Schätzungen werden frühzeitig in den ersten Projektphasen erstellt. Eine erste Schätzung sollte spätestens während der Definitionsphase erfolgen. Da bei einer Erstschätzung noch viele unbekannte Größen vorhanden sind, fällt diese meist nicht sehr genau aus und bedarf einer stetigen Korrektur im weiteren Projektverlauf. Auch wenn diese Schätzung ungenau ausfällt, ist diese aber vor allem für den Auftraggeber wichtig, da sie erstmals Aussagen über Kosten- und Zeitaufwand ermöglicht</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9474 2007-06-16T15:38:15Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9473 2007-06-16T15:37:48Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandsschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> <br /> [[Kategorie:Aufwandschätzung]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9472 2007-06-16T15:37:10Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandsschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> Wenn die Definitionen und/oder die Anmerkungen nicht von einem selbst stammen, sollte man die Quellen angeben<br /> (das sind natürlich nur Beispiele, keine echten Quellen dieses Artikels :-) ):<br /> <br /> *Hinz und Kunz, &quot;Der Bau einer Musterseite&quot;, 7. Auflage, Wiki-Verlag, 1931<br /> <br /> Besser ist es spezielle Quellendokumente zu erstellen (und diese dann auch mit Inhalt zu füllen):<br /> <br /> *[[Bundschuh, Manfred; Fabry, Axel (2004): Aufwandschätzung von IT-Projekten]]<br /> *[[Goldratt, E.; Cox , J. (2004): The Goal]]<br /> *[[Leach, L. (2005): Critical Chain Project Management]]<br /> <br /> [[Kategorie:Aufwandschätzung]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9471 2007-06-16T15:33:42Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandsschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien einige davon genannt.<br /> <br /> So werden zum einem Erfahrungen, welche mit ähnlichen Projekten gemacht werden zurückgewiesen oder nicht beachtet, da man der Auffassung ist, dass dieses Problem nicht auftreten würden oder man es gar dieses Mal besser machen würde. Weiterhin wird eine Schätzung oftmals als Verhandlungssache ausgelegt um sich bei Vertragsverhandlungen erfolgreich durchsetzen zu können um letztendlich den Zuschlag für das Projekt zu bekommen.<br /> <br /> Ein weiterer fataler Fehler ist es, das Schätzobjekt, also das entstehende Produkt, nicht genau genug zu betrachten. Bei der Betrachtung eines Schätzobjektes gilt: je mehr Informationen über das Schätzobjekt je genauer die Schätzung. Als Informationen kann man sich aus Softwaresicht beispielsweise die Anzahl und den Umfang von Schnittstellen, die Abläufe aus Benutzersicht (Use Cases) oder das Datenmodell des entstehenden Produktes vorstellen.<br /> <br /> Bei Zeit und/oder Kostendruck können diese Informationen nicht so genau erfasst werden, da sich die Entwickler nicht lange genug mit dem Produkt auseinander setzen können, wie es eigentlich für eine erfolgreiche Schätzung nötig wäre.<br /> <br /> In manchen Fällen ist nicht mal der Zeit und/oder Kostendruck ausschlaggebend für eine ungenügende Schätzung. So werden teilweise ansprechend durchdachte Schätzungen durch den Projektleiter abgelehnt, da diese schlicht und ergreifendend eine zu lange Entwicklungsdauer zu Tage bringen.<br /> <br /> Die hier genannten Gründe bilden nur einen kleinen Ausschnitt an Problemen, welche eine vernünftige Schätzung nicht realisierbar machen. Daher ist es nicht verwunderlich, dass nach einer Studie der [[Standish Group]] aus dem Jahre 2003 gut zwei Drittel aller Projekte als misslungen anzusehen sind.<br /> <br /> <br /> =Quellen=<br /> Wenn die Definitionen und/oder die Anmerkungen nicht von einem selbst stammen, sollte man die Quellen angeben<br /> (das sind natürlich nur Beispiele, keine echten Quellen dieses Artikels :-) ):<br /> <br /> *Hinz und Kunz, &quot;Der Bau einer Musterseite&quot;, 7. Auflage, Wiki-Verlag, 1931<br /> <br /> Besser ist es spezielle Quellendokumente zu erstellen (und diese dann auch mit Inhalt zu füllen):<br /> <br /> *[[Kowarschick, W. et al. (2005): Musterquelle (Buch)]]<br /> *[[Goldratt, E.; Cox , J. (2004): The Goal]]<br /> *[[Leach, L. (2005): Critical Chain Project Management]]<br /> <br /> [[Kategorie:Aufwandschätzung]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Sch%C3%A4tzproblematik&diff=9470 2007-06-16T15:32:16Z

<p>Wilben: </p> <hr /> <div>{{In Bearbeitung}}<br /> <br /> Aufwandsschätzungen können zu meist nicht ordentlich abgeschlossen werden, obwohl eine mangelhafte Schätzung keine gute Basis für ein Projekt darstellt. Es gibt vielerlei Gründe warum gute Schätzungen bereits von vornherein nahezu unmöglich sind. Im folgenden seien <br /> <br /> =Quellen=<br /> Wenn die Definitionen und/oder die Anmerkungen nicht von einem selbst stammen, sollte man die Quellen angeben<br /> (das sind natürlich nur Beispiele, keine echten Quellen dieses Artikels :-) ):<br /> <br /> *Hinz und Kunz, &quot;Der Bau einer Musterseite&quot;, 7. Auflage, Wiki-Verlag, 1931<br /> <br /> Besser ist es spezielle Quellendokumente zu erstellen (und diese dann auch mit Inhalt zu füllen):<br /> <br /> *[[Kowarschick, W. et al. (2005): Musterquelle (Buch)]]<br /> *[[Goldratt, E.; Cox , J. (2004): The Goal]]<br /> *[[Leach, L. (2005): Critical Chain Project Management]]<br /> <br /> [[Kategorie:Aufwandschätzung]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9456 2007-06-16T14:43:44Z

<p>Wilben: </p> <hr /> <div>[[Kategorie:Projektmanagement]]<br /> [[en:Category:Cost Estimate Project Management]]<br /> <br /> =Definition=<br /> Schätzungen werden frühzeitig in den ersten Projektphasen erstellt. Eine erste Schätzung sollte spätestens während der Definitionsphase erfolgen. Da bei einer Erstschätzung noch viele unbekannte Größen vorhanden sind, fällt diese meist nicht sehr genau aus und bedarf einer stetigen Korrektur im weiteren Projektverlauf. Auch wenn diese Schätzung ungenau ausfällt, ist diese aber vor allem für den Auftraggeber wichtig, da sie erstmals Aussagen über Kosten- und Zeitaufwand ermöglicht</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9455 2007-06-16T14:40:17Z

<p>Wilben: </p> <hr /> <div>[[Kategorie:Projektmanagement]]<br /> [[en:Category:Cost Estimate Project Management]]</div>

Wilben https://glossar.hs-augsburg.de/w/index.php?title=Kategorie:Aufwandsch%C3%A4tzung&diff=9454 2007-06-16T14:39:38Z

<p>Wilben: </p> <hr /> <div>[[Kategorie:Projektmanagement]]<br /> [[Kategorie:Aufwandschätzung]]<br /> [[en:Category:Cost Estimate Project Management]]</div>

Wilben