We often receive questions regarding milestones, subtasks and workflows at AceProject customer service. AceProject does not support the concepts of “milestones” or “subtasks”. Depending on your specific needs, this FAQ might provide some feasible workarounds or not.

1. Milestones and high level “Project Portfolio” views

As mentioned above, AceProject does not support the concept of “milestones”. However, your organization might need to manage several or many projects in parallel in which case you want a higher-level view of where you stand on each of your projects. A possible workaround for you might be to use Project Statuses to reflect your “milestones”.

AceProject allows you to create as many project statuses as you need. Project statuses are divided into 3 categories:

  • “Waiting” project statuses
  • “In Progress” project statuses
  • “Completed” project statuses

Therefore, for example, if you need to provide, on a higher-level view, information related to the approval of your projects, you could have a project status called “Approval Pending” in the “Waiting” project status category. If you need to be more precise, you could add other statuses in the category.

Then, in the “In Progress” category, you could have project statuses such as the following:

  • “Project Approved – Milestone a achieved”
  • “Project Approved – Milestone b achieved”
  • “Project Approved – Milestone c achieved”

Finally, in the “Completed” project status category, you could have statuses such as:

  • “Project Dropped”
  • “Project Completed”

Since AceProject does not display completed projects by default, nor tasks therein, all  a project manager must do to stop all work on his/her project is to change the project status to a “Completed” status. Having a project status called “Project Dropped” in the “Completed” category has the added benefits of providing managers precise information on the project and retaining all historical data with regards to the project.

2. Workflows

Your organization might want to standardize its workflows and essentially have the application guide you on the steps that need to be done next on your projects. AceProject has 2 mechanisms designed to handle workflows:

  • task statuses
  • task dependencies

When you can manage to represent your different steps on a task as task statuses, the idea is to have an assigned user change the status to the next appropriate Task Status once he/she has completed his/her step. AceProject then automatically sends out e-mail notifications to the other assignees and reviewers on the task. Hence, a prerequisite to using task statuses to handle workflows is to assign on a task all individuals who need to perform at least one step on the task. The “Details” field may be used to provide further information on who performs each step.

An advantage using task statuses provides is the fact that you can associate a “Predefined % Done” value to each task status. That means that the user does not have to worry about updating the % Done value on a task, AceProject handles it automatically when the task status is changed.

There are disadvantages to using task statuses though. If you have different categories of tasks in your project, you cannot have separate sets of task status values by Task Group or Task Type. All tasks in your project will share the same set of task status values. You therefore have to be generic enough so that your task statuses apply to any type of task in your project or you might need to have a very high number of task status values in your project which makes things more difficult on your users who need to find the next appropriate task status to change the task to.

The other solution to handling workflows is task dependencies. If you set up tasks and dependencies between your tasks, AceProject will send out an e-mail automatically to a user assigned on a successor task as soon as it may be started (as soon as all its predecessors have been set to completed).

If you work with dependencies, odds are that each or most of the tasks will be assigned to a single user. Hence, from a project’s Incomplete Tasks list, it is more obvious who you are waiting upon for the next steps to be done.

The drawback with using dependencies is that the number of tasks will be increased considerably. You will also probably want to use the Show/Hide Columns feature to display the “Ready to start” field and make it your 1st criterion in your task list sorting order so that tasks that cannot be started yet (because one or several predecessors have not yet been completed) do not appear at the top of your task list.

So those are the 2 options you have with regards to handling workflows. Now, a few final thoughts regarding workflows and the 2 suggestions on how to implement them…

Once you have represented a workflow in a project (either through task statuses or dependencies), you can then mark your project as a template. Thus, if similar projects come along later, you can use your template as the basis for your new project. When you create a new project based on a template, all your Task Group, Task Type, Task Priority and Task Status values are automatically copied over to your new project. Tasks and their dependencies can also be copied over.

Finally, for the higher-level view, you might want to set up task statuses or tasks (on tasks that are assigned to a project manager) that tell the project manager to change the status of the project once a “milestone” has been reached.

Leave a Reply