If you have a few moments could you describe your suggestions on using the Projects feature?

[althegr...@gmail.com]

Greetings!

If you have a few moments could you describe your suggestions on using the Projects feature?

I have read the help page on Projects and experimented with the aspects of the Projects field. I believe I understand the mechanics of Projects but feel I don't "grok" using Projects. Perhaps you can suggest a use case? I know that the Projects field is quite similar to the Context field and that field is replicated to all sub-tasks. I see the percent done graphic. I just feel a lack of certainty on when to use the Projects feature when I try to explain it to other people.

thanks,

Al

[pottster]

Hi Al,

Interesting question. Personally, I use the project functionality in a separate data file containing all my projects. The file also contains my life goals and each of the projects is cross referred to achieving a life goal. I've attached a screenshot showing the Outline structure.

[Dwight Arthur]

On Tuesday, November 24, 2015 at 5:37:53 AM UTC-5, althegr...@gmail.com wrote:

If you have a few moments could you describe your suggestions on using the Projects feature?

Hi, Al.

To me (others will differ) the key to effectively using MLO is in the views. There are many other powerful features, but to me, the value of each is in what it enables the views to select/hide/sort/group/show. So the question to me is, what can you do on a report with a project that you cannot do with a folder full of tasks or a task with a lot of subtasks.

And it bears mentioning that you can make complex and powerful project-like series of tasks without ever using a project. You can use "tasks in order" and dependencies to ensure that you get the prerequisites done by the point where you need them. You can use the "next action" filter without projects. You could even create a folder or a parent task called "Project: migrate to new accounting package" and then make a view of items named "project" and branch below each. All without using projects.

So the first question is, why do you need to think of your tasks as projects, irrespective of whether you designate them in MLO as projects.

For the most part, my tasks fall into one of three types. There is the ongoing routine stuff, much of which falls into repeating scheduled efforts ("quarterly routine" includes a task "replace filters"). Then there is the one-shot stuff that comes up and needs to be dealt with ("order a case of filters" and "received case of filters?"). And then there are some bigger initiatives that typically involve a series of steps, things to be waited for and workstreams to be started up when the waiting is over. These are each something that matters, that cannot be allowed to get lost or neglected for long, but that go on across multiple days and that I need to be sure that I get back to. For me, these are projects. 

So: the first benefit: by calling them projects I cause them to show up on my Projects view. Every day, at least once, I look at the Projects view to see if anything is looking neglected and if adequate progress is being made. I try to keep the number of open projects below 15 as I believe that above that I will not be able to meaningfully interact with all of them every day.

My projects view is actually a collapsed Next Actions view so I can hit f7 and see the next action for each project. In order to avoid a lengthy list of next actions under "Project: none" I added an advanced filter "ProjectName is not empty". Now, I could have built my projects as tasks with subtasks, with the word "project" in the caption. Each one would have to be at root level in order for Next Action to work. Building the view would be possible but not easy. It's a lot easier and more convenient to just make them projects.

Second benefit: projects can show a progress bar. I have a mental image of how far along each of my projects ought to be at this point in time, and it only takes a few seconds to glance at the project list and see if anything's dragging behind. 

Hop this helps,

-Dwight

[Nick Clark]

Another benefit is that the Project Title can show as part of the task in Task views. This helps keep Task names simple and repeatable, so the task "Send email to team" is related to the project.

[althegr...@gmail.com]

Hi Pottster,

Thanks for sharing your innovative idea!

 

Linking to other files is covered in the Help manual and your idea is a great Use Case of an implementation of the MLO feature. I will be implementing your strategy!  I might also use your idea to move my huge list of checklists to another file too.

 

I also liked your use of the MLO Automatic Formatting Rules! I am attaching a screenshot collage of the steps to make Goals have the Green color from your example in case others want to color their Goal tasks.

 

Thanks very much for taking the time to share your thoughts,

Al

[althegr...@gmail.com]

Thanks everyone for sharing your ideas and thoughts.

 

After several hours of thought and MLO experiments I have further qualified my original question to:

 

Functionally - Why did the MLO team put the field "Project" into the system when the Project Title ("Buy House") could be put into the Context field?

 

The Project field is quite similar to the Context field.

 

Advantages of having a Project field:

 

• The Task Title of the Parent Task (The Project's Name "Buy House") is automatically entered into ALL the subtasks in the Task branch of the tree.

 

• The Project field in the subtasks can NOT be altered or deleted.
• In the Context field, the words that make the project's title CAN be altered or even deleted. IF the Context field in a sub task is altered ("Buy Hous " - missing "e"), then when checking off subtasks in a Next Action view is Halted and the remaining step in the branch are NOT presented because that task doesn't have the same Context spelling / name as the rest of the branch - Therefore the rest of the projects sub tasks don't show up to be done! 

 

• If the TITLE of the Project changes from "Buy House" to anything else ("Buy Beach House") - ALL the subtasks in the Project branch are automatically renamed to the Parent Project Title. :)

 

• A BIG help is when there are LOTS of Project titles. IF the Project titles had to be put into the Context field then the Context List would be bloated by that number of project Title words - (Buy House; Buy Beach House; Buy Castle; Fix brakes on blue car; etc….. ) for a Context List that would be cumbersome to scroll thru.

 

• Because of the Project Title words being put into the Project field, the Context field is kept smaller.
• When a project is deleted from the Outline (tree) - All the Project Title words are automatically removed from the Project field. If the Project title words were stored in the Context field - EACH Project title set of words would have to be manually deleted from the Context List.

 

• By using the Project field, the entire branch from the Parent Task to the very bottom branch & leaf is held together as a unit that can't be accidently altered.

 

• A new task that is put into a Branch that is a project has it's Project field automatically set to the Parent's Project name.

 

• A task in a branch with a different parent can not have it's Project field set to the same Project name where you CAN do that with the Context field.

 

There are more advantages, including all those covered in the MLO Help, but these are advantages that helped me understand why I would want to use Projects instead of putting everything in to the Context field (list).

 

I attached a graphic file showing the same project twice, one as a Project and the other NOT a project. I commented the graphic - I hope you might find the above of interest.

 

Please leave any further thoughts, suggestions or questions in the post.

 

Thanks,

Al

[Elizabeth Lindsay]

I follow the more classical Getting Things Done (GTD) approach.  Therefore, a project is any goal that takes more than one action to complete and a context is where/what I need to get it done.

For example, I have a project to "Embroider a Christmas Stocking".

Task 1: Create design.  Context: @Computer (because I need to use software to create it).

Task 2: Stitch design.  Context: @Craft Room (where my machine lives).

Task 3: Deliver product.  Context: @Away (since I'll be away from my house).

In addition, I use the feature to add the project as a prefix to the task name.  This helps distinguish similar items that are for other projects (such as creating a design for a shirt, not the stocking).

I hope that helps,

Elizabeth