This blog is a series from the original blog post where we discussed how you could improve the conversion rate by preparing a good proposal document. The link to the original blog is mentioned here on medium
In this blog, we discuss the other documentation samples which can help you to manage your project effectively. IN this blog we share some of our best practices to create these documents and some samples which can be used to getting started
These are the documents which we are going to discuss.
What it should have: It should capture all detailed discussions which you have had with your client till date. This is the consolidated document which defines why a particular solution was selected and addresses any issues which the management or client may have.
After the initial discussion and design workshops which you may have had with the client, it is essential to now focus on the solution offering. This is a much-condensed version of the AS-IS solution and it may require you to update it in various versions.
Now one of the most important document is the technical design document. I am not including any specific template for this one as it depends a lot on the programming language that you’ll use.
In the case at hand, we have delivered projects in SAP, JavaScript, and C#. We ensure the basic sketch of the document remains as below. One important thing to note is the fact that the code snippet should always be included. The document should holistically represent what you did and anyone who was not a part of the project should be able to read and understand from the document that the project is about and what is the expected project approach and deliverables
A matrix which shows what all KT you plan to cover and who are it’s intended audience. Attached is one of the KT plan I created. It includes
A sample training document is as attached. A right set of the document should consist of
With these set of documents you should be able to execute and deliver a project successfully end to end, thereby gaining your client confidence by projecting your methodological approach.The best practice of documentation depends on what kind of project you are in. An implementation project which has a UI may need a UX design approach whereas a backend project may not require any UI to be implemented so you can skip that.
Most of these documents need to be tweaked according to your project technical skills being used and your clients requirement but these documents should give a good starting point to be used in the project