Inhaltsverzeichnis:
- Angebotslänge
- Zusammenfassung
- Die Vorlage
- Projekttitel
- Inhaltsverzeichnis
- Zulassungen
- Änderungen
- Glossar und Akronyme
- Umfang
- Zeitleiste
- Projektmitglieder
- Geschäftsmöglichkeit
- Lösungsüberblick
- Funktionen und Leistungen
- Budget und ROI
- Leistungen
- Einschränkungen
So schreiben Sie einen erfolgreichen Softwareentwicklungsvorschlag.
Kevin Languedoc
Der Zweck eines Softwareentwicklungsvorschlags besteht darin, eine Lösung zu vermitteln, die von Geschäftsleuten gelesen wird. Halten Sie sie daher einfach und auf den Punkt. Halten Sie sich so weit wie möglich von Fachbegriffen fern. Die folgende Übersicht kann unverändert verwendet werden, um einen erfolgreichen Softwareentwicklungsvorschlag vorzubereiten. Es ist wichtig zu bedenken, dass die Personen, denen Sie den Vorschlag vorlegen, nicht viel Zeit haben, um ein langes Dokument zu lesen. Sie können es mir nehmen, ich habe in mehr als 20 Jahren in der Informationstechnologie Hunderte von Vorschlägen geschrieben: Geschäftsleute wollen gerade genug Informationen, um eine fundierte Entscheidung treffen zu können.
Wenn Sie auf eine Angebotsanfrage (RFP) antworten und einen bestimmten Seitenbereich einhalten müssen, weil die Seiten vorgedruckt sind oder die Inhaltsanforderungen Sie zu einem übermäßig langen Angebot zwingen, sollten Sie eine Zusammenfassung in Betracht ziehen. Ich habe einen Abschnitt hinzugefügt, der beschreibt, wie man einen vorbereitet.
Angebotslänge
Ich habe Vorlagen und Diskussionen gesehen, die Vorschläge befürworten, die 50 oder mehr Seiten umfassen. Glauben Sie mir, Sie werden nach der fünften Seite das Interesse des Geschäftsführers verlieren. Sobald der Vorschlag angenommen wurde, werden die Entwurfsunterlagen natürlich detaillierter sein, da sie für das Projektteam bestimmt sind und die Arbeitspläne für das System darstellen. Dies gilt für die meisten Kunden, aber (ja, es gibt immer ein Aber) wenn der Vorschlag auf eine Angebotsanfrage (RFP) reagiert, müssen Sie sich an die Ausschreibung halten. Außerdem wird eine Regierung oder Militärbehörde wahrscheinlich strenge Richtlinien für die Erstellung eines Softwareentwicklungsvorschlags haben und kann je nach Komplexität des Systems mehrere Seiten (10, 20, 30, 50 oder mehr) enthalten.Diese Regel gilt weiterhin für große Organisationen, die möglicherweise ein formelles Antragsverfahren haben, insbesondere wenn sie eine Aktiengesellschaft sind und sich an Sarbannes-Oxley- oder ISO-Vorschriften oder -Standards halten müssen.
Zusammenfassung
Wenn der Vorschlag mehr als 20 Seiten umfasst, können Sie eine Zusammenfassung bereitstellen, die nur einen Pager der Abschnitte des Vorschlags enthält. Sie können sogar eine Zusammenfassung in einem PowerPoint-Format bereitstellen. Wenn Sie planen, eine Zusammenfassung in der Präsentation des Softwareentwicklungsvorschlags zu verwenden, präsentieren Sie den Vorschlag in der Zusammenfassung, und die Führungskraft kann den Vorschlag zu einem späteren Zeitpunkt lesen, beispielsweise während eines Geschäftsfluges.
Die Vorlage
Die folgende Übersicht ist eine gute Vorlage, mit der Sie Ihren eigenen Softwareentwicklungsvorschlag erstellen können. Ich denke bei der Ausarbeitung eines Vorschlags immer an die Elevator Pitch-Regel, und das sollten Sie auch. Grundsätzlich sieht der Aufzugsabstand vor, dass Ihr Vorschlag nicht viel länger sein sollte als die Zeit, die erforderlich ist, um einen Aufzug vom Erdgeschoss in die oberste Etage eines Gebäudes zu bringen, während Sie einen Vorschlag vorlegen.
Projekttitel
Mit Untertitel oder zusammengefassten Informationen zum Vorschlag
Der Vorschlag sollte einen Titel und einen Unterabschnitt enthalten, der den Kontext des Softwarevorschlags zusammenfasst. Sie geben auch den Namen der Abteilung, des Dienstes, der Abteilung oder der Organisation an, für die das Projekt bestimmt ist.
Wenn Sie auf eine Ausschreibung (Request For Proposal) antworten, fügen Sie alle erforderlichen oder in der Ausschreibung als obligatorisch aufgeführten Informationen hinzu. Ich habe auch RFPs gesehen, in denen Sie aufgefordert werden, die Genehmigungssignaturen zusätzlich zum Titel auf der ersten Seite zu platzieren. In diesem Beispiel habe ich die Signaturen jedoch auf der Seite mit dem Abschnitt "Änderungen" platziert.
Inhaltsverzeichnis
Auf der nächsten Seite sollten Sie ein Inhaltsverzeichnis mit den wichtigsten Abschnitten des Vorschlags einfügen. Sie können die Seitenzahlen optional angeben, wenn der Vorschlag mehr als fünf Seiten umfasst oder vom RFP gefordert wird.
Zulassungen
Dieser Abschnitt ist für den Prozess von entscheidender Bedeutung, unabhängig davon, ob es sich um eine Antwort auf eine Ausschreibung, eine Vorlage oder eine andere Quelle handelt. Dieser Abschnitt dokumentiert die Bestätigungen, dass das Projekt erfolgreich ist, und enthält eine verbindliche Vereinbarung zwischen den verschiedenen Mitgliedern des Projekts. Sie sollten niemals ein Projekt starten, bevor Sie nicht alle erforderlichen Unterschriften erhalten haben und sich vom Projektleiter und den Stakeholdern verpflichtet haben, mit dem Projekt zu beginnen. Andernfalls könnten Sie sich in einer Bindung befinden, wenn das Projekt abgebrochen wird oder wenn sich der Umfang des Projekts oder die zu erbringenden Leistungen ändern.
Mit den vorhandenen Genehmigungen sind Änderungen des Umfangs und der zu erbringenden Leistungen viel schwieriger vorzunehmen, und wenn es zu Streitigkeiten kommt, wird die Unterzeichnung von Genehmigungen ein klares (er) Verständnis dafür vermitteln, was vereinbart wurde. Natürlich gibt es immer eine Frage der Interpretation.
Die Zulassungen sollten den Namen der Person, ihren Titel, gefolgt von ihrer Unterschrift und schließlich das Datum der Unterzeichnung des Dokuments enthalten.
Name | Titelrolle | Unterschrift | Datum |
---|---|---|---|
Änderungen
Der Abschnitt "Änderungen" enthält ein Protokoll aller Änderungen, die am Dokument "Software Development Proposal" vorgenommen wurden oder vorgenommen werden. Es werden keine Änderungen am Umfang des Projekts selbst oder an anderen Aspekten des Projekts dokumentiert. Der Abschnitt Änderungen sollte mindestens den Namen der Person, die die Änderung vornimmt, das Datum der Änderung sowie einen Kommentar oder eine Beschreibung der Änderung enthalten.
Autor | Datum der Änderung | Beschreibung oder Kommentar |
---|---|---|
Glossar und Akronyme
Listen Sie alle Begriffe oder Akronyme und ihre Definitionen auf. Gehen Sie nicht davon aus, dass jeder die Bedeutung von Begriffen oder Akronymen kennt, insbesondere wenn Sie externe Berater einsetzen möchten und die Begriffe intern sind und in Ihre Unternehmenskultur und Ihren Jargon eingebettet sind. Jede Organisation hat ihren eigenen Jargon und ihre eigenen Akronyme. Es ist in Ordnung, sie im Vorschlag zu verwenden, solange sie ordnungsgemäß dokumentiert sind.
Auch wenn branchenspezifische Akronyme verwendet werden, müssen diese ebenfalls dokumentiert werden, damit jeder die Bedeutung der Begriffe und Akronyme klar versteht und bessere Interpretationen formuliert.
Die folgenden Akronyme stammen aus der aktuellen Vorlage. Sie dienen als Beispiel.
- RFP: Angebotsanfrage
- ROI: Return on Investment
- CAGR: Compound Annual Growth Rate
- IT: Informationstechnologie
- CAPEX: Investitionen
- UoM: Maßeinheit
Umfang
Der Umfang des Vorschlags sollte auf hoher Ebene die Gesamtdetails des Projekts sowie die Ein- und Ausschlüsse umreißen. Der Umfang sollte eine Gesamtbeschreibung, die Länge des Projekts und die Hauptziele enthalten. Was möchten Sie mit dieser Investition in das vorgeschlagene Softwareentwicklungsprojekt erreichen?
Zeitleiste
Dieser Abschnitt enthält die Start- und Enddaten (geschätzt). Stellen Sie sicher, dass Sie einen Puffer einbauen und Eventualitäten einplanen. Eine gute Faustregel ist, Ihrer Zeitleiste einen Puffer von 75% hinzuzufügen.
Projektmitglieder
Zu den Projektmitgliedern sollten der Projektchampion und die Stakeholder gehören. Der Champion ist normalerweise eine Führungskraft, die das Gesamtprojekt und das Budget steuert. Der Stakeholder ist normalerweise ein interner Promoter oder Sponsor. Sie können auch der Champion sein, abhängig vom Umfang des Projekts und der Art der Organisation, die den Softwareentwicklungsvorschlag anfordert. Die verbleibende Liste enthält typische Rollen, die Personen in einem Projekt ausführen.
Das Folgende ist nur ein Beispiel für die Art der Rollen, die Projektteilnehmer möglicherweise haben. Einige Leute können mehr als eine Rolle haben. Je nach Umfang des Projekts kann die Liste der Projektmitglieder sehr lang sein oder dieselbe Person kann unterschiedliche Rollen übernehmen.
Die Liste sollte alle Informationen enthalten, die die Person, ihre Rolle innerhalb des Projekts, ihre Erreichbarkeit und ihre Verantwortlichkeiten ordnungsgemäß identifizieren. Sie können andere Informationen hinzufügen, abhängig von der Ausschreibung oder der Art der Organisation, mit der Sie arbeiten, und ihren internen Richtlinien.
Teammitglied | Rolle | Kontakt Informationen | Verantwortlichkeiten |
---|---|---|---|
Champion |
|||
Interessengruppen |
|||
Projektmanager |
|||
Architekt |
|||
Analytiker |
|||
Entwickler |
Geschäftsmöglichkeit
Die meisten verfügbaren Vorlagen definieren diesen Abschnitt als „Geschäftsproblem“ oder „Problemstellung“. Ich bin jedoch häufig auf Führungskräfte gestoßen, die die Tatsache beleidigen, dass sie ein Problem in ihrer Geschäftseinheit oder ihrem Geschäftsprozess haben. Ich erinnere mich, dass eine Direktorin mich buchstäblich aus ihrem Büro geworfen hat, weil ich erklärt hatte, dass wir einen Prozess reparieren und sie mir sagte, dass es nicht jemand aus der IT (Informationstechnologie) sein würde, der diktieren würde, ob sie ein Problem hat mit ihren Prozessen oder nicht.
Seien Sie also vorsichtig mit dem Wortlaut. Ich verwende immer den Begriff „Geschäftsmöglichkeit“, da der Vorschlag letztendlich eine Geschäftsmöglichkeit darstellt, um einen Prozess zu verbessern, einen Prozess zu unterstützen oder einen Prozess zu automatisieren
Geschäftsauszug | Wie das System die Anforderung erfüllt |
---|---|
Betroffener Geschäftsprozess, Situation, Problem |
Wie wird die vorgeschlagene Lösung den Zielgeschäftsbereich verbessern? |
Welcher Bedarf wird angesprochen? |
Wie wird das aktuelle Projekt damit umgehen? |
Lösungsüberblick
Im Abschnitt Lösungsübersicht können Sie einen allgemeinen Überblick über das System geben. Diese Übersicht kann eine Navigationskarte enthalten, wenn der Vorschlag für eine Website oder eine Web-App gilt. Sie können auch ein Flussdiagramm des Prozessablaufs einfügen. Sie können auch ein Diagramm der Hauptkomponenten des Systems einfügen.
Ziel ist es, der Person, die die Entscheidung trifft, genügend Informationen zu geben, damit sie versteht, was das System ist, wie es funktioniert und was die Hauptbausteine sind. Dies ist natürlich nur eine Richtlinie, da eine Organisation möglicherweise ein formelles Format hat, das definiert, was Sie in dem Vorschlag angeben müssen, insbesondere wenn Sie es mit einer Regierungsbehörde oder dem Verteidigungsministerium zu tun haben.
Funktionen und Leistungen
Dieser Abschnitt bietet einen Mechanismus zum Zuordnen eines Merkmals des vorgeschlagenen Systems zu einem konkreten Ergebnis. Ich habe auch gesehen, dass dieser Abschnitt eine Zeitschätzung enthält, um das Ergebnis zu vervollständigen, aber ich mag es nicht, diese zu verwenden, da sie zu restriktiv ist und eine Verbindung herstellt. Bei der Arbeit an dem Projekt werden die Ergebnisse möglicherweise nicht genau so ausgerichtet, wie sie aufgeschrieben sind Wenn Sie sich also auf dem Papier verpflichtet haben, ein Ergebnis bis zu einem bestimmten Zeitpunkt fertigzustellen, wird die Elastizität später, wenn Sie das Projekt tatsächlich durchführen, entfernt oder verringert.
Eine weitere Spalte, die hinzugefügt werden kann, ist das Release, zu dem das Ergebnis gehört. Dies ist praktisch, wenn das Projekt über einen längeren Zeitraum geliefert wird und mehrere Releases vorliegen. Dies kann auch für ein Agile- oder Lean-basiertes Projekt gelten, bei dem jede Funktion oder User Story zu einem Release gehört.
Das Konzept ist einfach; Geben Sie für jedes Merkmal im System den Namen des Merkmals, eine kurze Beschreibung und das Ergebnis an, das die Merkmalsanforderungen erfüllt.
Feature | Beschreibung | Lieferbar |
---|---|---|
Budget und ROI
Das Budget und der ROI sind für einige Führungskräfte wahrscheinlich der wichtigste Teil. Sie alle sind gespannt, wie viel das System sie kosten wird oder welche Auswirkungen dieses Projekt auf ihr Abteilungsbudget haben wird. Dies gilt insbesondere dann, wenn das Projekt zu Beginn des Geschäftsjahres nicht in den Capex enthalten war.
Selbst wenn das Projekt budgetiert wurde, hat manchmal ein anderes Projekt Vorrang vor dem aktuellen Vorschlag, und die Mittel können von der beabsichtigten Quelle abgezweigt werden. Auf der Ebene der Exekutive und des Managements kommt es häufig zu politischen Auseinandersetzungen, um ein Projekt auf den Weg zu bringen, und es gibt oft unvorhergesehene Umstände, die Vorrang vor geplanten Projekten haben können.
Seien Sie also bereit, mit Ihren Stakeholdern zusammenzuarbeiten, um bei Verhandlungen zu helfen, oder seien Sie flexibel und proaktiv, um eine funktionierende Lösung bereitzustellen, wenn eine Budgetsituation seitwärts geht. Es ist besser, das Projekt an die Haushaltsrealität anzupassen und die Systemergebnisse sogar über einen längeren Zeitraum zu verteilen oder sich sogar vom Projekt zu entfernen. Es ist weitaus besser, wegzugehen, als an einem Projekt gearbeitet zu haben und nicht bezahlt zu werden und später auf Rechtsstreitigkeiten zurückgreifen zu müssen.
Die folgende Tabelle dient nur zu Demonstrationszwecken, um Ihnen eine Vorstellung davon zu geben, wie Sie ein Budget erstellen. Natürlich müssen Sie Ihre eigenen Werbebuchungen hinzufügen, um sie an Ihr Projekt anzupassen. Dann geben Sie die Menge, den Stückpreis, die Maßeinheit und die Gesamtsumme der Werbebuchung ein. Zählen Sie dann die Werbebuchungssummen unten auf.
Dies liefert ein gutes Bild der Investition, die für das Softwareprojekt erforderlich ist. Die meisten Führungskräfte, mit denen ich zusammengearbeitet habe, möchten wissen, wie hoch die Rendite sein wird oder wie viel dieses Projekt im Laufe der Zeit kosten wird. Daher füge ich auch einen einfachen ROI-Wert und eine CAGR hinzu, entweder unter Verwendung meiner eigenen Schätzungen und Annahmen (die sein müssen) erklärt) im Vorschlag oder unter Verwendung der bereitgestellten Schätzungen und Annahmen.
Projektelement | Menge | Einzelpreis | UoM | Gesamt |
---|---|---|---|---|
Softwarelizenz |
||||
Maschine (n) |
||||
Serverlizenz |
||||
Datenbanklizenz |
||||
Entwicklungsberater |
||||
Projektmanagement |
||||
Training (Zeit + Materialien) |
ROI
Die ROI-Berechnung ist sehr einfach. Grundsätzlich lautet die Formel Gewinne - Kosten geteilt durch Kosten. Die Formel ist unten angegeben:
Der einzige Nachteil ist, dass die Berechnung keine Zeit berücksichtigt. Daher ist der ROI für kurzfristige Projekte gut, aber für längerfristige Projekte schließe ich im Allgemeinen eine CAGR (Compound Annual Growth Rate) ein. Die CAGR-Berechnung ist eine Jahresrendite für einen bestimmten Zeitpunkt.
CAGR
Die CAGR-Formel lautet:
Der erste Teil ist die Division des Endwerts durch den Startwert. Das Ergebnis wird über die Anzahl der investierten Jahre auf 1 erhöht. Der resultierende Wert wird von 1 subtrahiert.
Leistungen
In diesem Abschnitt listen Sie die Geschäftsvorteile auf, die das Softwareprojekt bietet. Sie können im Aufzählungszeichenformat aufgeführt werden, solange sie mit den Gesamtzielen übereinstimmen. Sie sollten zeigen, wie die Software oder das System den Geschäftswert steigern.
Kurz gesagt, wie wird die vorgeschlagene Lösung dem Unternehmen helfen, erfolgreicher zu sein und seine erklärten Ziele zu erreichen? Verwenden Sie positive Wörter und Sätze.
Einschränkungen
Der Abschnitt Einschränkungen sollte alle materiellen und immateriellen Einschränkungen auflisten, die Sie vorhersehen können. Dies kann sich auf Geräte beziehen, einige saisonale Faktoren wie die Stilllegung einer Produktionsanlage, die die meisten Anlagen beispielsweise mindestens einmal im Jahr durchführen.
Versuchen Sie, die Einschränkungen herunterzuspielen oder als minimal zu bezeichnen. Listen Sie keine negativen Aspekte der Software oder des Systems auf oder stellen Sie, falls erforderlich, Problemumgehungslösungen bereit.
© 2012 Kevin Languedoc