Comment rédiger une proposition de développement logiciel

Comment rédiger une proposition de développement logiciel réussie.

Kevin Languedoc

Le but d'une proposition de développement logiciel est de véhiculer une solution qui sera lue par les gens d'affaires, alors restez simple et concis; éviter autant que possible les termes techniques. Le plan suivant peut être utilisé tel quel pour préparer une proposition de développement logiciel réussie. Il est important de garder à l'esprit que les personnes à qui vous allez présenter la proposition n'ont pas beaucoup de temps pour lire un long document. Vous pouvez me le croire, j'ai rédigé des centaines de propositions au cours de mes 20 ans et plus dans les technologies de l'information: les gens d'affaires veulent juste assez d'informations pour leur permettre de prendre une décision éclairée.

Si vous répondez à une demande de proposition (RFP) et que vous devez respecter une certaine plage de pages, parce que les pages sont pré-imprimées ou que les exigences de contenu vous obligent à avoir une proposition trop longue, envisagez d'utiliser un résumé. J'ai ajouté une section décrivant comment en préparer un ci-dessous.

Durée de la proposition

J'ai vu des modèles et des discussions qui préconisent des propositions qui durent 50 ou pages. Croyez-moi, vous perdrez l'intérêt du chef d'entreprise après la cinquième page. Une fois la proposition acceptée, les documents de conception seront naturellement plus détaillés car ils seront destinés à l'équipe de projet et constitueront les plans de travail du système. Cela s'appliquera à la plupart des clients, mais (oui, il y a toujours un mais) si la proposition est en réponse à une demande de proposition (RFP), vous devez adhérer à la demande de propositions. En outre, un gouvernement ou une agence militaire aura probablement des directives strictes sur la façon de préparer une proposition de développement de logiciel et peut inclure plusieurs pages (10, 20, 30, 50 ou plus) en fonction de la complexité du système.Cette règle est toujours valable pour les grandes organisations qui peuvent avoir un processus de proposition formel, surtout si elles sont une entreprise publique et doivent adhérer à toute réglementation ou norme Sarbannes-Oxley ou ISO.

Résumé

Si la proposition fait plus de 20 pages, vous pouvez envisager de fournir un résumé analytique qui est une page des sections de la proposition. Vous pouvez même fournir un résumé au format PowerPoint. Si vous prévoyez d'utiliser un résumé analytique dans la présentation de la proposition de développement de logiciel, présentez la proposition à l'aide du résumé exécutif et l'exécutif peut lire la proposition à un moment ultérieur, comme lors d'un vol d'affaires.

Le gabarit

Le plan suivant est en fait un bon modèle que vous pouvez utiliser pour préparer votre propre proposition de développement logiciel. Je garde toujours à l'esprit la règle d'ascenseur lors de la préparation d'une proposition, et vous devriez aussi. Fondamentalement, le pitch de l'ascenseur stipule que votre proposition ne doit pas être beaucoup plus longue que le temps qu'il faut pour prendre un ascenseur du rez-de-chaussée au dernier étage d'un immeuble sur votre chemin pour présenter une proposition.

Titre du projet

Avec un sous-titre ou des informations résumées sur la proposition

La proposition doit avoir un titre et une sous-section résumant le contexte de la proposition de logiciel. Vous incluez également le nom de la division, du service, du département ou de l'organisation auquel le projet est destiné.

Si vous répondez à un RFP (Request For Proposal), incluez les informations requises ou répertoriées comme obligatoires dans la DP. J'ai également vu des appels d'offres qui vous demandent de mettre les signatures d'approbation en plus du titre sur la première page, mais dans cet exemple, j'ai mis les signatures sur la page avec la section Modifications.

Table des matières

Sur la page suivante, vous devez inclure une table des matières répertoriant les principales sections de la proposition. Vous pouvez éventuellement inclure les numéros de page si la proposition dépasse cinq pages ou si elle est requise par la RFP.

Approbations

Cette section est cruciale pour le processus, qu'il s'agisse d'une réponse à une demande de propositions ou de ce modèle ou d'une autre source. Cette section documente les confirmations que le projet est en cours et fournit un accord contraignant entre les différents membres du projet. Vous ne devez jamais démarrer un projet avant d'avoir obtenu toutes les signatures nécessaires et un engagement du champion du projet et des parties prenantes pour commencer le projet. Sinon, vous pourriez vous retrouver dans une liaison si le projet est annulé ou si la portée du projet change ou les livrables.

Avec les approbations en place, les modifications de la portée et des produits livrables sont beaucoup plus difficiles à faire et en cas de différend, avoir signé les approbations fournira une (plus) claire compréhension de ce qui a été convenu. Bien sûr, il y a toujours une question d'interprétation.

Les approbations doivent inclure le nom de la personne, son titre, suivi de sa signature et enfin la date à laquelle le document a été signé.



Nom	Titre / rôle	Signature	Date

Changements

La section Modifications fournit un journal de toutes les modifications qui ont été apportées ou seront apportées au document de proposition de développement logiciel. Il ne documente aucune modification de la portée du projet lui-même ou de tout autre aspect du projet. La section Modifications doit inclure au minimum le nom de la personne effectuant la modification, la date de la modification et un commentaire ou une description de la modification.



Auteur	Date du changement	Description ou commentaire

Glossaire et acronymes

Énumérez tous les termes ou acronymes et leurs définitions. Ne supposez pas que tout le monde connaît la signification des termes ou des acronymes, surtout si vous prévoyez de faire appel à des consultants externes et que les termes sont internes, intégrés à votre culture d'entreprise et à votre jargon. Chaque organisation a son propre jargon et acronymes. Vous pouvez les utiliser dans la proposition tant qu’ils sont correctement documentés.

De plus, si des acronymes spécifiques à l'industrie sont utilisés, ils doivent également être documentés afin que chacun comprenne clairement la signification des termes et des acronymes et formule de meilleures interprétations.

Les acronymes suivants proviennent du modèle actuel. Ils sont fournis à titre d'exemple.

RFP: demande de proposition
ROI: retour sur investissement
TCAC: taux de croissance annuel composé
IT: technologie de l'information
CAPEX: dépenses en capital
UoM: unité de mesure

Portée

Le champ d'application de la proposition doit décrire à un niveau élevé les détails généraux du projet, ce qui est inclus et exclu. La portée doit fournir une description globale, la durée du projet, les principaux objectifs. Qu'essayez-vous d'accomplir avec cet investissement dans le projet de développement logiciel proposé.

Chronologie

Cette section comprendra les dates de début et de fin (estimées). Assurez-vous de créer un tampon et de prévoir les imprévus. Une bonne règle de base consiste à ajouter un tampon de 75% à votre chronologie.

Membres du projet

Les membres du projet doivent inclure le champion du projet et les parties prenantes. Le champion est généralement un cadre qui dirige l'ensemble du projet et du budget. La partie prenante est généralement un promoteur ou un sponsor interne. Ils peuvent également être le champion en fonction de la portée du projet et / ou du type d'organisation qui demande la proposition de développement logiciel. La liste restante contient les rôles typiques que les personnes exécutent dans un projet.

Ce qui suit n'est fourni qu'à titre d'exemple du type de rôles que les participants au projet peuvent avoir. Certaines personnes peuvent avoir plus d'un rôle. En fonction de la portée du projet, la liste des membres du projet peut être très longue ou la même personne peut assumer des rôles différents.

La liste doit contenir toute information qui identifie correctement la personne, son rôle dans le projet, comment la joindre et quelles sont ses responsabilités. Vous pouvez inclure d'autres informations selon la demande de propositions ou le type d'organisation avec laquelle vous travaillerez et leurs politiques internes.



Membre de l'équipe	Rôle	Coordonnées	Responsabilités
	Champion
	Partie prenante
	Chef de projet
	Architecte
	Analyste
	Développeur

Opportunité commerciale

La plupart des modèles disponibles définissent cette section comme «Problème commercial» ou «Énoncé du problème». Cependant, j'ai souvent rencontré des chefs d'entreprise qui s'offusquent du fait qu'ils ont un problème dans leur unité commerciale ou processus. Je me souviens d'une directrice qui m'a littéralement jeté hors de son bureau parce que j'avais déclaré que nous étions en train de réparer un processus et elle m'a dit que ce ne serait pas quelqu'un de l'informatique (technologie de l'information) qui allait lui dicter si elle avait un problème avec ses processus ou pas.

Soyez donc prudent avec le libellé. J'utilise toujours le terme «opportunité commerciale» car au final, la proposition répond à une opportunité commerciale pour améliorer un processus, soutenir un processus ou automatiser un processus



Déclaration commerciale	Comment le système satisfera à l'exigence
Processus métier, situation, problème concernés	Comment la solution proposée améliorera-t-elle le secteur d'activité cible
Quel besoin est satisfait	Comment le projet actuel va-t-il y remédier

Vue d'ensemble de la solution

Dans la section Présentation de la solution, vous pouvez fournir une vue d'ensemble du système. Cet aperçu peut inclure une carte de navigation si la proposition concerne un site Web ou une application Web. Vous pouvez également inclure un organigramme du flux de processus. Vous pouvez également inclure un diagramme des principaux composants du système.

L'objectif ici est de donner à la personne qui prend la décision suffisamment d'informations pour qu'elle comprenne en quoi consiste le système, comment il fonctionnera et quels sont les principaux éléments constitutifs. Bien sûr, il ne s'agit que d'une ligne directrice car une organisation peut avoir un format formel qui définit ce que vous devrez fournir dans la proposition, en particulier si vous avez affaire à une agence gouvernementale ou au ministère de la Défense.

Caractéristiques et produits livrables

Cette section fournit un mécanisme pour mapper une caractéristique du système proposé à un produit livrable tangible. J'ai également vu cette section contenant une estimation du temps nécessaire pour terminer le livrable, mais je n'aime pas l'utiliser car elle est trop restrictive et crée un lien. Lorsque vous travaillez sur le projet, les livrables peuvent ne pas s'aligner exactement comme ils sont écrits, donc si vous vous êtes engagé sur papier à terminer un livrable avant un certain temps, cela supprime ou diminue toute élasticité plus tard, lorsque vous réalisez réellement le projet.

Une autre colonne qui peut être ajoutée est la version à laquelle appartient le livrable. Ceci est pratique si le projet sera livré sur une période plus longue et s'il y aura plusieurs versions. Cela peut également s'appliquer à un projet basé sur Agile ou Lean où chaque fonctionnalité ou user story appartient à une version.

Le concept est simple; pour chaque fonction du système, indiquez le nom de la fonction, une brève description et le livrable qui satisfera les exigences de la fonction.



Fonctionnalité	La description	Livrable

Budget et ROI

Le budget et le retour sur investissement sont probablement la partie la plus importante pour certains dirigeants. Ils ont tous hâte de savoir combien le système leur coûtera ou quel impact ce projet aura sur le budget de leur département. Cela est particulièrement vrai si le projet n'a pas été inclus dans les Capex au début de l'exercice.

Parfois, même si le projet a été budgété, un autre projet peut avoir préséance sur la proposition actuelle et les fonds peuvent être détournés de leur source prévue. Il y a souvent un peu de querelles politiques au niveau de la direction et de la direction pour faire décoller un projet et il y a souvent des circonstances imprévues qui peuvent primer sur les projets planifiés.

Soyez donc prêt à travailler avec votre partie prenante pour aider dans les négociations ou soyez flexible et proactif pour fournir une solution de travail si une situation budgétaire va de travers. Il est préférable d'adapter le projet à la réalité budgétaire, voire d'étaler les livrables du système sur une plus longue période ou même de s'éloigner du projet. Il vaut bien mieux s'en aller que d'avoir travaillé sur un projet et de ne pas être payé et de devoir recourir à des litiges plus tard.

Le tableau suivant est à des fins de démonstration uniquement pour vous donner une idée de la façon de préparer un budget. Naturellement, vous devrez ajouter vos propres éléments de campagne en fonction de votre projet. Ensuite, vous remplissez la quantité, le prix unitaire, l'unité de mesure et le total de l'article. Additionnez ensuite les totaux des éléments de campagne en bas.

Cela donnera une bonne image de l'investissement nécessaire pour réaliser le projet logiciel. La plupart des cadres avec lesquels j'ai travaillé aiment savoir quel sera le taux de rendement ou combien ce projet coûtera au fil du temps, donc j'inclus également une valeur de retour sur investissement simple et un TCAC, soit en utilisant mes propres estimations et hypothèses (qui doivent être expliqué) dans la proposition ou en utilisant les estimations et hypothèses fournies.



Élément de projet	Montant	Prix unitaire	UoM	Total
Licence de logiciel
Machines)
Licence serveur
Licence de base de données
Consultant en développement
Gestion de projet
Formation (temps + matériel)

ROI

Le calcul du ROI est très simple. Fondamentalement, la formule est gains - coût divisé par coût. La formule est fournie ci-dessous:

Le seul inconvénient est que le calcul ne prend pas en compte le temps, donc le retour sur investissement est bon pour les projets à court terme mais pour les projets à plus long terme, j'inclus généralement un TCAC (taux de croissance annuel composé). Le calcul du TCAC est un taux de rendement d'une année sur l'autre pour un certain moment dans le temps.

CAGR

La formule CAGR est:

La première partie est la division de la valeur finale par la valeur initiale. Le résultat est porté à la puissance 1 sur le nombre d'années investies. La valeur résultante est soustraite de 1.

Avantages

Dans cette section, vous répertoriez les avantages commerciaux que le projet logiciel offrira. Ils peuvent être listés sous forme de puces à condition qu'ils correspondent aux objectifs généraux. Ils doivent démontrer comment le logiciel ou le système améliorera la valeur commerciale.

En un mot, comment la solution proposée aidera-t-elle l'entreprise à mieux réussir et à atteindre ses objectifs déclarés? Utilisez des mots et des phrases positifs.

Contraintes

La section des contraintes doit répertorier toutes les contraintes tangibles et intangibles que vous pouvez prévoir. Cela peut concerner l'équipement, un facteur de saisonnalité comme la fermeture d'une usine de production, ce que la plupart des usines font au moins une fois par an à titre d'exemple.

Essayez de minimiser les contraintes ou de les peindre comme étant minimales. Ne listez pas les aspects négatifs du logiciel ou du système ou si vous devez le faire, fournissez des solutions de contournement.