One "pointer" would be how a graduate student proposed their Ph.D. dissertation project. There is a lot of variety here. The way I did it was (1) pick my own practical problem I brought to graduate school, (2) in my first summer use some of the best material from my first year of course work to do some original research to get a solution, (3) write up the solution as a 50 page manuscript. That became my 'dissertation proposal'. The key to the 'process' here was that the manuscript had its core content in theorems and proofs. So, there wasn't a lot of doubt.

Later I finished my Ph.D. just as outlined in my manuscript.

Here's another example: I was working for a small company near DC on some DoD problems. At one point we had to bid on a software project for a major DoD lab. Part of the work was to provide data for a simulation of effects of ocean waves. Some of the input was actual ocean wave data. So, the goal was to generate simulated data with the same 'power spectrum' as observed. I got the famous book by Blackman and Tukey on measurement of power spectra and discovered that what the DoD lab wanted was poorly formulated; they were asking for too much 'resolution' from the data they had.. So, following the book, I wrote some software to illustrate what could and could not be done. The software, my references to Blackman and Tukey, and a technical paper I wrote formed the solid core of our proposal. We got the contact. The software I had written actually was essentially what was needed in the final deliverable.

I was in an industrial research group working on monitoring the health and wellness of server farms and networks. I had some new ideas and wrote out the ideas, with theorems and proofs, in a paper. Then I wrote some prototype software. On both simulated and real data, my software worked just as the math in my paper said it would. I wrote a paper for publication, and it was published. What's in the paper is solid and likely and apparently remains the best way to detect 'zero day' problems in server farms and networks. And for the "process", it is possible to be quite sure about the 'efficacy' of the work just from the paper.

The DoD accepts and reviews proposals for technical projects and research of wide variety. There is DARPA, ONR, Army Research at Durham, and more.

There is also design and planning in most of engineering, say, for tall buildings, long bridges, new airplane engines, new airplanes, etc.

In all such documents, the most serious question is, will the project as proposed yield the desired results? In nearly all cases, this question is answered just in the project proposal just on paper. Why such a paper is taken seriously is that, put briefly, 'it all hangs together logically from beginning to end'. Often the core of this logical connection is some math or math physics. That "process" of writing a paper that 'hangs together' is heavily from academic research. With this process, done well, it actually is quite possible to be fairly sure of the project results just from the project proposal just on paper before the project begins. The batting average of the DoD on such work, e.g., GPS, ARPANet, adaptive beam forming in passive sonar, inertial navagation, ultra low frequency radio communications, the SR-71, spread spectrum radar, infrared missile guidance, radar, the proximity fuse, the A-bomh, the H-bomb, the ICBMs, is nearly 100% and, thus, totally knocks the socks off venture capital.

Does this "process" have a role in information technology venture capital? At present, essentially never. Should it? Definitely, yes. How? Not for all projects but for the best ones, that is, the 'home runs': For an outline at 40,000 feet up, the standard steps in hitting an home run in business are (1) Pick a good problem, (2) Find a good solution to that good problem. (3) Sell the solution.

Part of being a 'good' problem is that a good solution will be valuable. Part of a good solution is that it is much more valuable as a solution than anything else and is difficult to duplicate or equal.

To ease the "process", pick a problem where it is obvious that a good solution would be valuable. Then for the solution, present that as a technical project proposal, say, much as for the US DoD, where all the proposal hangs together logically from beginning to end, likely with some math theorems and proofs and some math physics, etc.

Math? Information technology is to provide information by manipulating available data. Those manipulations are necessarily mathematical, understood or not, powerful or not. For manipulations that are solid and powerful, proceed mathematically.

Alas, US venture capital is nearly totally unable either to evaluate such work or even to direct the evaluation of such work. US citizens can be very glad for US national security that the US DoD is evaluating projects as they are and nothing like how VCs evaluate projects. Indeed, one could count on one hand all the VCs with qualifications to be technical problem sponsors in the NSF, DARPA, or the rest of the DoD. The IT VCs are trying to work in technical fields but nearly all are, in two words, technically incompetent.