Your project proposal often sets the tone on how the project will go. It helps define the timing, the price and the scope of the work. I’m sharing some of my favorite proposal tips to help make sure your projects stay on track. What are some of your favorite tricks to setting up a successful proposal? https://beyondthechaos.biz/project-proposal-project-success/
We also include assumptions. Even simple stuff like we assume Xojo can actually do what we believe it will do (occasionally it can’t). We assume the client will do some testing on their own (because sometimes they don’t think they’re responsible for any). We assume the client will provide timely feedback (waiting two weeks for a reply to an issue is not timely).
@Bob Keeney Those are great things to add. Anything you are assuming or expecting can be put into the document so that everyone is on the same page.
Most of this comes from the school of hard knocks. We actually had a client assume, once, that we would handle all of the support for their commercial application (for free which was even worse!). We never thought about it since we had never had a client do that before (or since), but it’s in the contract now because of that one time.
It is amazing what people will assume is included!
I realize that this discussion is primarily aimed at “for-hire” tasks, but we use a similar process for all projects in-house to prevent “hey, this sounds like a good idea” from becoming an impact to existing revenue work.
In our processes, the sales team presents the customer request / product idea to the product management team. That team then decides the feasibility of the feature/product and generates a specification that is submitted to me and our engineering lead. We examine the spec and then bring in the proper software or hardware team member to say yes / maybe / no.
If we get a yes (usually a feature request for an existing product), we then compare the spec to engineering reality. If the two are “close”, we move forward to provide an estimate of the time taking into account any issues that can result from dependence on our metal bender, internal talent, the abilities of the various software tools available, and other project schedules. If we get a maybe or the spec is lacking, we meet with the sales person and validate what they asked versus what they “think” they asked to better flesh out the spec. If they have a true idea of what the customer asked, the maybe becomes a yes, other wise it becomes a no and we move on.
Usually, this all occurs within a 2 hour window to keep things “agile” (something we’ve been doing since the 80s that didn’t have a fancy catch-phrase name back then).
What is interesting is that in 3 out of 5 software requests, the feature already exists and either
- The customer has not properly perused our documentation <_<
- The contact sales person doesn’t understand what the customer is asking x_x
- The engineers didn’t provide proper info to the tech writer so that the operation/feature WAS documented >_<
Usually the first or second, but I have had to “chat” with the engineer responsible on a few occasions.
@Tim Jones - Managing change is a huge challenge and I like your method. It’s like a mini-proposal every time you address changes.
I picked that up as a hardware product engineering manager at Archive back in the '80s. Even though we were working with hardware more than software in my group, we had to process even firmware changes that weren’t bug fixes in this manner. It came from the situation where what the customer (external or internal) “thought” they needed had no real life correlation to what they “really” needed. This process helped re-synchronize those two.
I have to work on that one. (I know I cannot do anything, but my tool unable to do anything is something I have to work on).
Thank you Susan.
[quote=380854:@Tim Jones]This process helped re-synchronize those two.
And you’re welcome @Emile Schwarz
WOW I wonder what they were smoking… We’ve had interesting clients too. Beware of clients who DO NOT care about proposals/contracts, red flag.