Ravi Nishesh Srivastava
Member since 3 years
Ravi Nishesh Srivastava
A Technology architect with 8 years of experience in GIS domain.
If I look at the basic definition of proposal, proposal is an offer to do a certain project for someone. It consists of Professional Summary, Technical Background, Architectures, Statistics, Feasibility, Terms, Protocols and most importantly a ‘Message’ which is not described or illustrated. The Message a proposal carries is a question to our customer/audience who review, approve, grant or fund that whether the proposition described in the proposal is suiting as per their requirement and is able to deliver a result or has any impediment.
In our regular practice of developing a proposal, we make it as it goes looking at the multiple perspectives like our own skill set, inputs from delivery team, information shared in the business demand document. We, Proposal Analysts/Managers, do work extensively to address the client need and submit the proposal to them as per the process which is followed across our organization.
Now, I look into another perspective of making a proposal. While addressing a business requirement which is Extensive, Lengthy, Time-Taking, requires Clarity and Focus, Commitment and most importantly Courage to address it, it becomes a ‘Project’ for those who work all round to develop a proposal. Though it may look little indistinct to someone but while analyzing the same in a Proposal Manager’s perspective, I am sure the thought process will little move on right track.
When we establish an order from a client to execute a project, we start mobilizing the team, do the extensive requirement assessment, design & develop, test & Deliver. And similarly we do the same while developing a technical proposal: finalizing the team who will work, deadlines, methodology to suggest for project execution, estimations, validations and finally delivering the proposal to our client. However, we need to always keep the room for our ‘Message’ which I mentioned in the beginning of this article.
Why I am more on describing the development of a proposal? I am just finding a suitable way to deliver this by looping it in a process. While we do implement several methodologies for projects, Can’t we do it for Proposal Development? In my perspective, in order to deliver a high quality technical proposal, if we use a project management methodology (We are assuming it as a project, isn’t it?) like Agile, the team and organization can be more productive to earn more business value. I hereby advocate the implementation of Scrum Framework in developing a technical proposal. Let’s see how feasible this could be while practicing it for same. Proposal team put lot of efforts in designing and developing data structures, architectures, flowchart, and project charter just for representing in the technical proposal which becomes a base when it comes to execute the same. I am sure following Scrum for all the front-ground and background work would yield a high quality proposal that may have higher winning probability.
If we put the entire context into the Scrum Framework, we can assume that our customer’s concerned stakeholder who is deriving the business demand could be the Product Owner. Another instance could be the Sales Team member who is located on a remote location and derives business values to be delivered on the basis of business demand document. The business value output would be a technical proposal which will carry a ‘Message’ which may or may not please customer, depends on how you have designed that ‘Message’. In any of the case, Product Owner will collect all the requirements as User Stories along with the Acceptance Criteria.
Looking at the Product Backlog and the schedules, it is decided on the number of sprints required to complete the project (the Proposal). Team (Team, in context of Scrum) takes up the items from the Product Backlog and put that in the Sprint Backlog during Sprint Planning. In order to make the Team do all the work defined for that Sprint and within that Sprint, Scrum Master intervene and analyze whether the tasks being given to the Team are doable or not within that Sprint or not? In case, any adjustments are required, Scrum Master discusses with Product Owner and justifies the context to be carried for a particular Sprint. It can also be understood that the development of a technical proposal would be small activity when compared to a Project to be executed, Scrum Master can also act as a member of Team and can support in development aspects based on the competency and skill he has.
In line of the putting Scrum for this kind of ‘Mini-Projects’ (in Proposal Manager’s perspective), the major part to understand is the Schedule. If it is an activity which requires 2-3 months or more to deliver a proposal, then Scrum framework can be applied in order to make it high quality, relevant and most importantly a low risk document. Else, we should go ahead with traditional way of developing it.
Daily Standup meeting would be an essential part to see what is happening in the line of developing a proposal by analyzing the past day, plans for current day and identifying the impediments. In case of any impediments, Scrum Master will try his best to resolve and make the team more productive. Looking at the perspective of Proposal Manager, the impediments could be No/Less Inputs from Delivery Team on time, Pressure from Product Owner, and Less Synchronization within team members etc. It is Scrum Master’s duty to manage this and produce a high quality technical proposal.
At every Sprint, the progress of the proposal can be assessed in the Sprint Review in the presence of all the stakeholders. This will give a fair idea of assessing where the team is and what are the areas which need attention in next sprint. Sprint Retrospective will give more relevancies on the way to completely develop the proposal. According to the progress of work as per Sprint Backlog, the Product Backlog is refined by Product Owner and subsequently communicated to the team in accordance with Scrum Master. Need to mention that a product (proposal, in this case) need to meet the acceptance criteria and should meet the definition of done in every sprint, else it cannot be treated as a completed/partially completed work. Needless to mention that every Sprint will produce a potentially shippable product.
The complete idea is not so easy to make it executable on one thought. Various conditions move around this complete idea right from the choice and availability of a person who can act as a Product Owner (being in the Scrum Framework) and adaptability of an organization to implement Scrum Practice for Proposal Development Practices. I think I have explained my idea here and will put more efforts on ideas on really executing this in further iterations. Till then, move your thoughts in that line and share. Good Luck.