Inactive projects can be active

[Christoph Zwerschke]

MLO has the concept of "active" tasks,
which means according to the help file:

1) no open subtasks
2) no completed parents
3) no future start date
4) not a folder
5) not "hide in todo"
6) next if "complete in order"
7) no open dependencies

However, I just noticed that an important criterion is missing:

8) if it's a project or inside a project,
the status of he project must be "in progress"

It does not make sense to me to count tasks in projects which have not
been started or have been completed or suspended as "active".

Or am I misunderstanding something?

-- Chris

[Stéph]

I agree. 

This is an example of the flexibility of MLO getting in the way of quick use. The Project status parameter is completely independent of task status and the checkbox.  Hence, you can have a project which isn't checked off, but is "suspended" or "completed".  Similarly, a checked off project can be "in progress" and one with tasks which have been checked off can be "not started". 

This doesn't make much sense to me and I've argued for better linking between related parameters in a previous thread.

Stéphane

[Christoph Zwerschke]

Am 20.07.2015 um 11:18 schrieb Stéph:
> This doesn't make much sense to me and I've argued for better linking
> between related parameters in a previous thread.

I don't understand how fruitful it is to argue on the mailing list and
whether the developers are even reading it, since I rarely see any
feedback or acknowledgment of issues except from other users.

So I've created a ticket on Uservoice:
http://mlo.uservoice.com/forums/9235-general/suggestions/8942713-honor-the-project-status-when-determining-active-t

Not sure whether this will get noticed more, particularly since I ran
out of votes and cannot even vote for my own suggestion any more ;-)

-- Chris

[Dwight Arthur]

Hi, Christoph.

I just want to make sure that you have considered creating your own custom views that would show active tasks excluding those that are in a project that's not in progress. It's easily done and I will show you the steps if you want.

I'm bringing this up because there are different ways of managing projects and this change would not always work well. In my projects, the time frim project kickoff through delivery to customer is critically important and closely tracked, and it's during that period that the project is considered "in progress." But there are tasks before that period, like analyzing requirements, producing estimate, preparing a formal bid, verifying customer's receipt of bid, and after that period, like verifying receipt of payment filing all project documents and archiving project data files. I need these tasks to be active even if the project isn't.

Using MLO's advanced filters to exclude some tasks from a view is pretty straightforward. Using the advanced filter to add tasks that had been excluded is much more difficult.
-Dwight

--
You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized.
To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/55ACCEFD.6040201%40online.de.
For more options, visit https://groups.google.com/d/optout.

[Christoph Zwerschke]

Am 20.07.2015 um 15:45 schrieb Dwight Arthur:
> I just want to make sure that you have considered creating your own
> custom views that would show active tasks excluding those that are in
> a project that's not in progress. It's easily done and I will show
> you the steps if you want.

Thanks for reminding me, you're right - an additional advanced filter
with "ProjectStatus=In Progress" would do that. However, I would need to
add this in several views that reference Active Actions, and I'm not
sure whether the "active" status is used elsewhere in MLO. Also, I think
a software should do the most obvious thing without needing to manually
tweak it.

> I'm bringing this up because there are different ways of managing
> projects and this change would not always work well. In my projects,
> the time frim project kickoff through delivery to customer is
> critically important and closely tracked, and it's during that period
> that the project is considered "in progress." But there are tasks
> before that period, like analyzing requirements, producing estimate,
> preparing a formal bid, verifying customer's receipt of bid, and
> after that period, like verifying receipt of payment filing all
> project documents and archiving project data files. I need these
> tasks to be active even if the project isn't.

This could be solved by adding another project state like "incubating"
between "not started" and "in progress" which would be considered
"active" as well.

-- Chris

[Dwight Arthur]

Am 20.07.2015 um 10:13 schrieb Christoph Zwerschke:
> This could be solved by adding another project state like "incubating"
> between "not started" and "in progress" which would be considered
> "active" as well.

Yes, that would be an improvement. But there would have to be one more called "shutdown" or "cleanup" just before completion.

[Christoph Zwerschke]

Am 20.07.2015 um 16:21 schrieb Dwight Arthur:
> Yes, that would be an improvement. But there would have to be one more called "shutdown" or "cleanup" just before completion.

Yes, makes sense. That status should then also be considered "active".

[Joel Azaria]

This conversation actually bodes well for an improvement I've wanted which is to define my own statuses.   We would be able to define which statuses represent Active tasks then and the project statuses could more closely mirror the statuses people have in real life.

For example IRL a project for us can be in many statuses* including Discovery, Feasibility (study), Design, Bid (out for), etc.

One of these statuses is 'exploded' projects.  These are projects that have ended but were not "completed" properly (ie. lost in bidding or otherwise, client/projects I've fired, been warned against or just decided otherwise to 'pass' on, the occasional/unfortunate less than stellar final outcome, etc.)  

I use these as a metric and when I do process reviews/writeups these jog my memory and remind of lessons learned.  Presently I can't/don't denote these projects in MLO so I have to review my paper folders' system ( I keep the exploders sorted separately for that but it's messy (files in multiple sort orders/places)) 

So here is just one use case;  it would be MUCH better for me to be able to review this in MLO than on paper.

(and yes I probably could mock up some workaround or another based on flags or contexts but having project statuses conform to the way they are in the rest of my real-life systems are really the answer

* For example our project bidding and design software uses these project statuses:  Discovery, Feasibility (study), Design, Bid (out for), Negotiation/"Value Engineering", Awarded (Internal 'expansion' from Proposal to actual Project including assignment of production Project Number), Staging (JIT Purchasing), Bench/Pre-build (rack building), Rough-In (an In-Process construction state), Trim-Out (In-Proc constr state), Programming & Finish (In-Proc constr state), Commisioning, Training, In-warranty support, On-Boarding, Maintenance Plan support, Out of warranty, Blocked and Exploded. 

Tracking our sales pipeline would add a small handful more to that.  These are all valid project states that we use for filtering projects and focusing on what needs to be done, delegated, tracked and/or pushed.

[Christoph Zwerschke]

Am 02.08.2015 um 02:41 schrieb Joel Azaria:
> One of these statuses is 'exploded' projects. These are projects that
> have ended but were not "completed" properly (ie. lost in bidding or
> otherwise, client/projects I've fired, been warned against or just
> decided otherwise to 'pass' on, the occasional/unfortunate less than
> stellar final outcome, etc.)

Yes, might be useful to distinguish these states. Some ticketing systems
have this distinction, "closed successfully" and "closed
unsuccessfully". The best thing would be to make it user configurable,
an let the user define which states are active and which are not.

-- Chris

[Joel Azaria]

Agreed.