How do you handle that project tasks are able to start before project is 'started'

[kellykaufmann]

What do you all do about project tasks being able to be worked on & updated before the project's 'Start project' button is clicked? Once the task state is updated, it automatically puts the project as started, and if the task is completed and has a successor then the successor task state is auto-changed to WIP. We can lock down the project task form for projects not yet 'started', but thought I'd ask how others are handling this. Also, if a team has VTB's of all open tasks assigned to them, they'll also see tasks of projects not yet started....what do you do about this?

Thanks for your help!

- Kelly

[Uncle Rob]

What do you all do about project tasks being able to be worked on & updated before the project's 'Start project' button is clicked?

I think a certain amount of this is necessary as the definitions of tasks may change even before the work is scheduled to be executed.   Also, task   timelines are estimates anyway, so we need the freedom to start things "when we can" vs "when the planned start date is".

The auto-starting of the project does sound problematic though.   You may need to dig through some business rules or workflow to see what's causing that.  

[kellykaufmann]

This isn't so much about a specific task's start/end date not being set in stone. This is more that people are seeing a project's tasks in their pre-made report of tasks assigned to them, but for a project not yet 'started'. So the poor PM is drafting the tasks in the project schedule for a project to kick off in a week, and 1 hour into drafting the project schedule, someone changes a task to WIP & starts working on it. A task that is WIP also can't tag a predecessor, etc. It changes the project start date to the date that person started working on the task as opposed to what the PM wants the project start date to be.

Starting a task when you can (early) that doesn't have any predecessors...for a project that is 'started' with the schedule (at least mostly) finished by the PM is one thing. Starting your task 5 minutes after the PM created the project and as the PM is 2 tasks into creating the schedule, and your task state changing is changing things for the PM a they are trying to build the schedule - that's a whole 'nother thing.

I guess we can also guide people when creating reports for project tasks add a filter that the project be open. This won't help though with the 'All work' report as I don't think you could do that type of filter on that report.

[Uncle Rob]

Yeah it definitely sounds like a control is needed to inhibit transition of P-Task to WIP if Project isn't Started.

Do you're Project Task states change to WIP on any user update automatically?

[kellykaufmann]

I know if you change the % complete of a task, the system auto-changes the state from 'Pending' to 'WIP' and ''starts' the project. I haven't tested every single field to see which ones trigger the state change.

Here's what I've identified thus far and have put into my training material. Note that we changed the logic to not change state to WIP but instead to change it to 'Open'. So replace 'Open' to WIP for your instance unless you've made the same changes

•Task states: Pending, Open, Work in Progress, Closed Complete, Closed Incomplete, Skipped.

—All tasks are in 'Pending' state until the project is 'started' or until someone makes a change to that task (e.g. update the % complete).

—When a project is 'started' and the first task is set to 'Start ASAP', the first task will automatically change from 'Pending' to 'Open'.

—When a predecessor task is closed, the successor task state will automatically change from 'Pending' to 'Open'.

—Once a task is started (in 'Open' or 'Work in Progress' state), can not change the time constraint of that task.

—Once a task is started, can not create a new predecessor for that task.