I considered that idea when writing the draft, but I don't think it's the best way to go in practice. It's much easier to explain benefits of something after you've explained what it is, IMO.
You are viewing a single comment's thread from:
I considered that idea when writing the draft, but I don't think it's the best way to go in practice. It's much easier to explain benefits of something after you've explained what it is, IMO.
Perhaps, and I see no reason why you couldn't do both, but if you don't explain the "Why" before you explain the "How", you leave the audience to guess that on their own or even worse, to not know.
I guess what I'm trying to get at is that they should define the problem first. That way you can more readily understand the reasons certain things are needed.
For example, I happen to know why you made this post because I witnessed the conversation you had on your other thread. You stated that sometimes the proposals are hard to understand. So to you and me, this proposal makes sense because we know what problem it fixes...we know "why" it is being suggested.
Others may simply view it as more bureaucracy being introduced into the process with no benefit and write it off on a glance without reading all the way to the end.
I don't think we're really far apart on this, as I kind of assumed that the root "why" should be addressed in the project summary, before the detailed description.
My intent with the benefits section was that someone could go into details about why their particular solution meets the more general need, which could only be explained easily after explaining the details of their solution.