You should be able to describe your business project in 140 characters or less. I don't have more time than that.
  -- @GAVollink

I've been following along with a pilot training program that was recently launched where I work.  One section of it is on a project definition framework.  I have never liked this framework, and only today - while responding to the trainer on another inquiry, did I finally understand why.  At the same time, I realized that I shouldn't dislike the framework at all...

I started implementing projects 18 years ago.  I started defining projects 12 years ago.  I started advocating projects from other peoples ideas almost 10 years ago.  Over the last 8 years, sometimes, I am the decision maker.  In all this time, I have never seen a project accepted by a decision maker for implementation because of how carefully documented it is.  Quite the opposite.  The project that can be described in two sentences - basically, twitter format - is most likely to get that person's attention.  The project that can get someone's attention an ALSO has a 30 second elevator pitch as a follow-up is rarely passed by.

That said, mounds of research and careful documentation is absolutely useful, essential even, about 20 minutes after the idea has been successfully pitched.  At the point it has been pitched, it will be a project, ready or not, so the details need to be ready too.  That's not the point.  What I've come to realize is that if someone has not thought through the project carefully enough to be able to isolate it to an introductory sound bite, and a follow-up paragraph, then the project probably is not ready to be done.

In some cases, it is a project that is supposed to be solving too many problems at once.  Something that is trying to fix everything is likely to be like a porcupine walking backwards through a silk shop.  In some cases, it is a project that would be best served as an add-on to a different project entirely.  In most cases, it is a project that is going to be waylaid by someone else's description of a problem.

When the project that can't be simply explained is swimming in a decision makers head, and someone else describes a problem, suddenly - because the project is not understood in the first place - the project and the problem are arbitrarily married.  The misguided ah-ha moment, "That must be what that project is for."

Coming back to the framework though, if there isn't a full project framework in place to back up that sound byte and elevator pitch, any technical person who is supposed to support that project going forward is going to expect that mound of research, the proof that this was really thought through.  Not having a well thought out plan for an idea that was already bought by a decision maker, will grow enemies quickly.  So my dislike for the framework is not about the framework, but the lack of the step where a sound byte and elevator pitch are distilled from that framework.

So, now I think of it this way; If I can't tweet a project description that makes sense, I'm not ready to pitch the project.  If I can't come up with a 30 second elevator speech to back up the tweet, then, I'm not ready to pitch the project.  If I don't follow the framework, too, then I don't even have a project to pitch.