How It Works

This page show how to develop work plan through chained asking process by using following lunch delivery project. 

Project Scenario: 
John is a salesman of catering service company and he got 100 lunch delivery order. To conduct this order, he must determine lunch menu, prepare food stuff, and cook. This Lunch delivery work plan can be developed by chained asking procedure as follows.


Number in the above diagram means following planning activity of each project member. 
  1. Sales_John issued “Top Request” to himself with due date Oct-18. This is a root of project planning tree.
  2. Sales_John added his “Menu Consultation Task” by 3 days duration.
  3. Sales_John issued(asked) “Cooking Request” to ChefMac. 
  4. Sales_John set time relation(red arrow) from “Consultation Task” to “Cooking Request”.
  5. Chef_Mac accepted “Cooking Request” and created his “Cooking Task” by 3 days duration.
  6. Chef_Mac issued(asked) “Food Stuff Shopping Request” to ShopperJane.
  7. Chef_Mac set time relation from “Shopping Request” to “Cooking Task”.
  8. Shopper_Jane accepted “Food Stuff Shopping Request” and created her “Shopping Task” by 3 days duration.
This page explain project planning process by project screen shot. If you want to know how to create request or task, please go to How to operate page. If you are 
courageous try first type person, please do click next link.

Open ChainOfAsker ver3 (<= This is free service. So If you are interested in this approach, please try!)
To use ChainOfAsker, Please install
    • ChainOfAsker starts up by new browser window(or tab). So you can easily try following operations by switching browser window(or tab).
    • ChainOfAsker is using on demand Google App Engine cloud computing service. So it may require additional application loading time (5 to 10 second)  when you start accessing.

Followings are screen shots of these planning activity.

Project planing phase

0: Initial screen

This is initial screen of ChainOfasker, so there is no project.

1: Sales_John issued top request
To develop lunch delivery project plan, Sales_John issued top request to himself with due date Oct-18. This top request has no valid child task so one day long temporally schedule bar is displayed after due date. Like this way, user can create multiple project under the "Me Related Project". 

ChainOfAsker does not distinguish who is project manager or who is a project member. so everyone can create new project and can send request to anyone.

2: Sales_John added menu consultation task
Sales_John  added his menu consultation task by 3 days duration under the top request. Then parent request duration is automatically  
changed to 
3 days because of added child task.

3days is just working day(except week end). It is 5 days when it include weekend.

3: Sales_John issued(asked) cooking request

Sales_John issued(asked) “Cooking Request” to ChefMac. This request has no valid child task, so system displayed one day long temporally schedule bar.

4: Sales_John set time relation

Sales_John set time relation from “Menu Consultation Task” to “Cooking Request”. And changed top request status to planned(see next) to notify ChainOfAsker system that he has created(issued) all required 
requests and tasks to realize accepted top request.  Distributed work planning system require this kind of planning finish flag in each planner to detect when planning phase is completed 
. Also u
ser is allowed to set time relation just for his/her created request and task so you never get unexpected time relation by other planner.

Sales_John's planning work is finished.

5: Chef_Mac added cooking task

Chef_Mac accepted “Cooking Request” and created his “Cooking Task” by 3 days duration. Now its parent(cooking request) duration is changed to 3 days and top request duration is changed to 6 days automatically by the effect of added child cooking task.

6: Chef_Mac issued(asked) shopping request 

Chef_Mac issued(asked) “Food Stuff Shopping Request” to ShopperJane. Again system displayed one day long temporally schedule bar because of no valid child task. 

Here we are assuming that Chef_Mac is a responsible person for kitchen work and have a right to control his member. So he (not Sales_John) selected shopper_Jane for shopping . These partitioned responsibility is very common in our work place.

Then we need work planning system which can delegate detail planning to the request receiver
 and organize these isolated work plan(tasks) to the whole project. This is the function which ChainOfAsker is providing.

7: Chef_Mac set time relation

Chef_Mac set time relation from “Shopping Request” to “Cooking Task” And changed cooking request status to planned to show that he has created(issued) all required requests and tasks to realize accepted cooking request.

Time relation between cooking task and shopping request is displayed by dark brown because these creator is Chef_Mac(current login user). So  Chef_Mac can add or delete time relation between these task and request. 

But please look at pale 
brown colored time relation between Menu consultation task and Cooking request these creator is Sales_John so he can set time relation between his consultation task and cooking request but Chef_mac can not because he is not the creator of the consultation task and cooking request. By this way, user will not get unexpected time relation from other member. 

8: Shopper_Jane added shopping task

Shopper_Jane accepted “Food Stuff Shopping Request” and created her “Shopping Task” by 3 days duration. 

After creating shopping task, she changed her accepted shopping request status to planned. Then system recognized that Req. Shopping has no new request(= request tree has reached its final executer) so system changed "Req. Shopping" status to child planned which means all of its descendant are planned. And this event is propagated to upper request and changed upper request status to child planned automatically. And now top request is child panned, it means all required work plan for this top request has been developed.

Project follow up phase

Sales_John completed his consultation task

 When Sales_John finished his consultation task, he changed his consultation task status to completed. Then progress % of consutation task and the progress % of its parent Top request are changed automatically and next shopping task become CanDo status.  

Shopper_Jane completed her food stuff shopping task

When Shopper_jane finished her shopping task, She changed her shopping task status to completed. Then parent Req shopping status change to completed status automatically because shopping task is the only one task under the shopping request so system recognize all task are completed for this request.  Completed status of the "Req.Shopping" is send to this request sender(Chef_Mac) to confirm the result of shopping.

Chef_Mac confirmed completion of Shopper_Jane’s shopping task

When Chef_Mac get completed notification for the shopping request, he check the result of food stuff preparation and if it is OK he change his issued request status to confirmed. Then next executable task(Cooking task) become CanDo status.

Chef_Mac completed his cooking task

When Chef_Mac finished his cooking task, He changed his cooking task status to completed. Then parent cooking request status is changed completed automatically because all of its children(cooking task and shopping request)  are completed. 

Sales_John confirmed completion of Chef_Mac’s cooking task

Finally Sales_John confirm his Cooking request. Then top request is confirmed automatically because Menu Consultation task has been completed and Req. Cooking is confirmed. And project is over.