"Art is never finished, only abandoned." (Leonardo Da Vinci)
1. Clearly identify why your are doing something.
2. Is it really a benefit to _both_ yourself and _society_ . Or are you solving someones issues for a false sense of accomplishment, and silly wages. Note, I do realize the irony of this post, but I find it entertaining so it still meets the criteria.
3. Summarize your time-bounded project goal in one sentence.
Example: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." (John F. Kennedy)
4. Draft the probabilistic path forwards, by adding the finish line first.
6. Are there people with the right skills and motivation to finish each stage of the project? Note, statistically if you are 93% sure you are only really 60% certain on average.
7. Justify the liability of the budget is consistent with personal and corporate budgets. Solving the worlds problems for free may sound noble, but a half-baked attempt is usually foolish, hapless, or destructive to yourself and others. i.e. if the only motive is to make something cheaper, than you will likely end up worse off for the effort.
8. Landing the belly flop... Can deliverables be re-used in other projects? Does the project still meet its goals in commercial, scientific, and or entertainment markets.
9. Start testing the hardest key deliverables first with toy sub-projects. If these don't succeed, than don't bother tooling up with funding for the rest of the project.
10. toy sub-projects are sometimes regression tests, small programs, or key problems with unknown solutions. Expect these to fail or be repurposed 52% of the time, but if they don't work for the intended role than the path is non-viable.
Finally, I must observe an interesting phenomena when the probability of completing a key deliverable is below 50%, number more the 3 nodes in a PERT serial traversal, and do not have redundant options. Irrespective of a project complexity, the team will fail to reach its goal regardless of the talent pool, time window, and budget.
1. Clearly identify why your are doing something.
2. Is it really a benefit to _both_ yourself and _society_ . Or are you solving someones issues for a false sense of accomplishment, and silly wages. Note, I do realize the irony of this post, but I find it entertaining so it still meets the criteria.
3. Summarize your time-bounded project goal in one sentence.
Example: “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." (John F. Kennedy)
4. Draft the probabilistic path forwards, by adding the finish line first.
https://en.wikipedia.org/wiki/Program_Evaluation_and_Review_...
5. Identify the key deliverables necessary to meet an MVP in your TRL. This narrows the scope of the project to mitigate feature creep etc.
https://en.wikipedia.org/wiki/Technology_readiness_level
6. Are there people with the right skills and motivation to finish each stage of the project? Note, statistically if you are 93% sure you are only really 60% certain on average.
7. Justify the liability of the budget is consistent with personal and corporate budgets. Solving the worlds problems for free may sound noble, but a half-baked attempt is usually foolish, hapless, or destructive to yourself and others. i.e. if the only motive is to make something cheaper, than you will likely end up worse off for the effort.
8. Landing the belly flop... Can deliverables be re-used in other projects? Does the project still meet its goals in commercial, scientific, and or entertainment markets.
9. Start testing the hardest key deliverables first with toy sub-projects. If these don't succeed, than don't bother tooling up with funding for the rest of the project.
10. toy sub-projects are sometimes regression tests, small programs, or key problems with unknown solutions. Expect these to fail or be repurposed 52% of the time, but if they don't work for the intended role than the path is non-viable.
Finally, I must observe an interesting phenomena when the probability of completing a key deliverable is below 50%, number more the 3 nodes in a PERT serial traversal, and do not have redundant options. Irrespective of a project complexity, the team will fail to reach its goal regardless of the talent pool, time window, and budget.
Best of luck, =3