Project method: Difference between revisions
Amwelladmin (talk | contribs) Created page with "{{a|project|}}To formulate a project: ===State the problem=== What is the testable question or problem you are trying to solve. For example: how to make the process of rev..." |
Amwelladmin (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{a| | {{a|projects|}}To formulate a project: | ||
===State the [[problem]]=== | ===State the [[problem]]=== | ||
What is the testable question or problem you are trying to solve. For example: how to make the process of reviewing a confi more effective. | What is the testable question or problem you are trying to solve. For example: how to make the process of reviewing a confi more effective. | ||
===Research and analysis=== | ===Research and analysis=== | ||
[[Problem solving|Problem-solve]] it: what is the problem? What is the ideal end goal? | Before solutionising, go through this process thoroughly. [[Problem solving|Problem-solve]] it: what is the problem? What is the ideal end goal? Don’t assume a given tool is the answer: it ''may'' be, but go through the critical phases of the process to identify whether fixing this particular aspect will make a difference. For example, if doc generation takes about 45 minutes of a three month negotiation process during which the negotiator spends 10-5 hours chasing various [[stakeholder]]s inside the organisation for comments, [[escalation]]s and responses, then [[document assembly]] probably isn’t the solution you are looking for. | ||
===Formulate solution=== | ===Formulate solution=== | ||
Once you have done that, formulate a proposed solution and some measurable success/failure criteria. Say you were using the [[Molesworth self-adjusting thank-you letter]] | Once you have done that, formulate a proposed solution and some measurable success/failure criteria. Say you were using the [[Molesworth self-adjusting thank-you letter]] | ||
{{sa}} | |||
*[[Sparklemotion]] | |||
Latest revision as of 19:07, 4 January 2021
|
The Devil’s Advocate™ — projects you can try at home
|
To formulate a project:
State the problem
What is the testable question or problem you are trying to solve. For example: how to make the process of reviewing a confi more effective.
Research and analysis
Before solutionising, go through this process thoroughly. Problem-solve it: what is the problem? What is the ideal end goal? Don’t assume a given tool is the answer: it may be, but go through the critical phases of the process to identify whether fixing this particular aspect will make a difference. For example, if doc generation takes about 45 minutes of a three month negotiation process during which the negotiator spends 10-5 hours chasing various stakeholders inside the organisation for comments, escalations and responses, then document assembly probably isn’t the solution you are looking for.
Formulate solution
Once you have done that, formulate a proposed solution and some measurable success/failure criteria. Say you were using the Molesworth self-adjusting thank-you letter