Why the Proposal Process has Always Been Agile
The latest craze surrounding Agile Proposal Management has puzzled me since its original buzz within the industry. When studying project management and Agile as part of my MBA program a few years ago, I immediately recognized proposal management as project management, and similarly recognized the long-standing proposal best practices to follow Agile. The notion that Agile proposal development is something new or innovative baffles me. This article will examine eight key Agile terms and draw their correlation to proposals and the proposal development process.
1. Agile Project Management: Agile Project Management is a term used to describe project management that uses Agile methodologies. This may include daily standups, collaboration among the stakeholders, continuous integration and availability of working product, etc.
Sounds familiar, doesn’t it? Since I can remember, daily standups, stakeholder collaboration, and continuous integration and availability of working product (drafts between color team reviews) have long been standard proposal best practices. I maintain that standard proposal management has always been Agile Project Management.
2. Backlog: A backlog is a collection of user stories and tasks that the team needs to complete. Product backlogs are related to the tasks to be done for the overall product while sprint backlogs are the ones that need to be completed in the current sprint.
I don’t know about you, but this sounds a lot like an Action Item list. I always maintain a running list of the tasks that need to be completed before the next color team review (sprint backlog) and that tasks that need to be completed before final submission (product backlog).
3. Iteration: An iteration is a period—typically 1 – 4 weeks long—when the agile development team produces the next increment of the product. At the beginning of the iteration, the product owner defines the requirements/tasks to be completed in the iteration. These requirements/task are agreed upon by the team.
When I manage proposals, I typically have my team develop the draft in iterations too. Depending on the length of the response period, these iterations typically last 1 – 4 weeks. After each of these iterations, we review the work in progress, and the start the next iteration.
4. Scrum: A Scrum is comprised of short iterations, called sprints, within which work is completed iteratively. The Scrum comprises three key roles: Product Owner, Scrum Master, and Scrum Team. The Scrum also involves four key activities: daily standup meeting, sprint planning meeting, sprint review meeting, and the retrospective meeting. With the exception of daily standup meeting (done everyday during the sprint) the other three are done once every sprint.
In my calculations, a proposal response effort in actuality is a Scrum. The Product Owner is simply what we have always called the Capture Manager. The Scrum Master is what we have always called the Proposal Manager. The Scrum Team is logically what we call the Proposal Team. Sprints are just the writing and development process that occurs between each color review, and the sprint review meetings are what we have called the color team reviews. The retrospective meeting? It’s another name for a lessons learned meeting. Maybe to be more “Agile,” proposals could add a brief lessons learned to each “sprint.”
5. Scrum Master: As noted previously, the Scrum Master is responsible for daily standup meetings and tracking the overall progress of the product development. The Scrum Master is charged with making sure the team is not blocked at any point of time due to external or internal issues. As alluded to earlier, this sounds a lot like the roles of a Proposal Manager, doesn’t it?
6. Sprint: We’ve touched on this already, but sprint is simply the Scrum term for an iteration. As mentioned previously, an iteration is a period when the development team works to produce the next increment of the finished product—for a proposal, the development period between each color review.
7. Stakeholder: Stakeholders are anyone outside of the team with vested interests in the working of the team and the products they develop. If you’ve worked on a proposal, you know there are many stakeholders involved, and their buy-in is critical to a successful proposal effort.
8. Stand up/Daily Meeting: This is noted as one of the most important activities in a Scrum-based approach. In a stand up meeting, the Scrum Team and Scrum Master sit and discuss the daily progress for a 15 – 30 minute period. A key point of Agile is the important of keeping these meetings short and precise. Daily stand-ups—so called because they should be so brief that you don’t need to sit down for them—have long been a best practice in the proposal development process. For some organizations, these have morphed into longer, more dreadful meetings, but that has never been the intent.
Do I think Agile Proposal Development is the way to go? Absolutely. However, I haven’t recently adopted this “innovative” approach to proposal management and development; I have practiced Agile Proposal Development my entire career. For this reason, I just haven’t been able to buy into the notion that Agile Proposal Development is something new or innovative. As this article has shown, our long-standing best practices in proposal development are inherently Agile—and these processes have been Agile long before Agile was the latest industry craze.
Written by Ashley Kayes, CP APMP
Senior Proposal Consultant, AOC Key Solutions, Inc. (KSI)
Thank you so much for taking the time to write this and to write it so well. I've wanted to make time to write this exact article for at least a year. Even if i had found the timed, I would not have integrated the Agile terminology and concepts nearly so well as you did. I enjoyed the "Agile Proposal Management" sessions I attended at last year's B&P con but there were so many times when i kept telling myself, "that's already what we do!" I liken it to Project Management. Proposal managers ARE project managers. And it took ages for that realization to reach widespread acknowledgement. Thank you again for a great contribution to the proposal management body of knowledge.ReplyDelete
Thank you so much for commenting! I am glad others are sharing this same perspective, and I have really enjoyed the discussion this has sparked on LinkedIn. I hope these discussions are continuing within individual organizations as well!ReplyDelete
Ashley, I like your analysis. There is a great deal of commonality between the two.ReplyDelete
What a terrific and timely message! THANK YOU!ReplyDelete
Thanks so much for commenting, Karen!Delete
The great service in this blog and the nice technology is visible in this blog. I am really very happy for the nice approach is visible in this blog and thank you very much for using the nice technology in this blogReplyDelete
IEEE Project Domain management in software engineering is distinct from traditional project deveopment in that software projects have a unique lifecycle process that requires multiple rounds of testing, updating, and faculty feedback. A IEEE Domain project Final Year Projects for CSE system development life cycle is essentially a phased project model that defines the organizational constraints of a large-scale systems project. The methods used in a IEEE DOmain Project systems development life cycle strategy Project Centers in India provide clearly defined phases of work to plan, design, test, deploy, and maintain information systems.ReplyDelete
I really appreciate your work which you have shared here. The article you have shared here is very informative and the points you have mentioned are very helpful. Thank you so much Agile Project Management Training OnlineReplyDelete
Mua vé máy bay tại đại lý Aivivu, tham khảoReplyDelete
mua ve may bay di my
chuyến bay cứu trợ mỹ về việt nam
vé máy bay từ đức về việt nam giá rẻ
lịch bay từ hà nội đến nga