Your proposal is one of the most important parts of your software development project. It defines price, terms, scope, timing, etc. A strong clear project proposal helps ensure you kick off your project with clear definition without any hint of chaos. In this video from Xojo Developer Conference 2018, I go over how you can best set up your project proposal.
Please find a full video transcript below:
Susan: They start with a proposal. If you’re starting later, you’re missing some steps. With proposals, one thing is you don’t want them to be more than three pages. If it’s more than three pages, you’re asking your client to agree to something they don’t understand. They’re not going to read. It’s too much.
If you do discovery first as one of your first steps, that can be its own proposal. But in this, I’m talking more about the actual project planning proposal. If you do a discovery proposal first, this, what we’re talking about, is more the project that comes from that discovery.
You want to define your scope very clearly by what the client gets, not necessarily what you’re going to do, but what the client’s going to get, so not technical specifications. They don’t understand that, and they’re not going to read it. In the end, when you want to go back to something to define the scope, you’re not on the same page. The proposal is setting that stage with your client to start off with everyone understanding what you’re getting to. If you’re giving them a bunch of technical stuff, they’re lost.
What you can say is something like, “I’m going to deliver you a one-page, sequentially numbered invoice that includes a place to enter a PO number and a payment received. It’s going to have six line items, and it calculates sales tax by tax and includes shipping information.” It’s pretty clear. It’s very defined, and they know what they’re getting.
Another thing you want to make sure is that you’re presenting a timeline or a deadline in that proposal. I know sometimes it’s hard to set a due date if you don’t know when they’re going to sign the proposal. Put an expiration date on your proposal. That also drives the sales process to get them to actually sign it.
If you’re doing this internal, if you’re an internal department, this applies as well as far as getting budgets approved. When I’m saying client, think internal client, internal, other departments you have to present to, your internal clients.
Once you have that in there, and it can be duration. You can say it’s going to be six to eight weeks, or it can be an actual date. I prefer the actual date. That actually gives you something to build a timeline against once your project starts. But if you’re going to do an estimated time frame, that’s okay too, as long as you’re setting some expectation of when it’s going to be delivered.
Duration is not your estimated hours. You guys all know that. If you say it’s going to take you eight hours to do it as far as a budget goes, that doesn’t mean the client’s getting it in eight hours. But that’s something to make clear as part of your proposal that that’s not the same thing to them.
One way that you can cut back on that deadline of, well, we don’t know how long it’s going to take, because what if they have changes? What if there are bugs? How long are those going to take to fix? What you can say in your proposal is you are going to receive something to test on this date. Then you have something that is more in your control to manage.
Obviously, you want to make sure you have a budget and payment terms part of it. If you’re doing a fixed price versus an estimated number of hours, it really doesn’t matter. The client sees that number as the number, what they’re paying. Your estimated hours in their head, it’s probably still a fixed price. Remember that when you’re putting that in there too.
Leave a Reply