[rangersanger]

I hadn’t seen this before and I’m 100% going to steal it and use it for my next product/feature/business case pitch. At least as a start to prove value to myself.

I’m fully aware of the utility of jargon in writing a business case, it lets me skip over the difficult, the warts, and the questionable. I wonder if there’s a correlation between failed projects and how jargon heavy the initiation is?

I also really like thinking about milestones as exam points. Calling them exams for success more directly gets at the point- to check in and course correct.

[xpe]

> I’m fully aware of the utility of jargon in writing a business case, it lets me skip over the difficult, the warts, and the questionable. I wonder if there’s a correlation between failed projects and how jargon heavy the initiation is?

I'll say this, based on my experience working at a particularly dysfunctional organization: in these kinds of environments, skipping over the most obvious questions seems to be the norm. Most of the time, when I was exposed to a new project, the explanation gave almost minimal explanation about fundamentals such as:

1. What is the time scale of the project? (e.g. weeks? (probably not), months? (that would be a moonshot), about a year? (maybe...), many years (yikes!))

2. What phase is the project in? (e.g. conceptualization, technical design, implementation, etc)

3. What specific teams and people are working on the project? Who is in charge? What kind of leadership will they offer? (e.g. selling the project up the ladder, project-level, technical, etc) ...

Also, the following questions were usually in play:

4. Where can I go read about the project details?

5. Why does it seem that each person who hears about the project has a very different idea of what it is supposed to do?

6. Wasn't there a previous version of this project? What was it called again? Did it ever launch? Why didn't it ever go anywhere?