natural treatment of hypothyroidism

User Guide / Projects Overview

Projects are the heart of progr.es: the entire application is designed to make running, managing and collaborating on projects easy and fun.

Projects are broken down into steps called milestones and tasks, with milestones being key steps that represent the completion of a collection tasks that must be completed in order to move to next phase of a project. To complete a project, the user must run through each of the steps, checking off each item as done, with milestones being required and tasks being optional.

Every project has two required steps: a start milestone and an end milestone, with completion of the start milestone starting the project and completion of the end milestone finishing it. Everything else, from having  tasks to adding notes to adding collaborators is entirely optional.

For a company selling a product the most basic example of this might be:

Start Milestone: Ordered received
End Milestone: Order shipped

Now that would give the company at least some sense that a project has started, is in process or has finished, but it would likely need to be fleshed out by adding intermediate milestones and tasks to be truly useful.

In terms of working out whether a step should be a milestone or task, that is up to the project creator; they must asses which steps are more significant than others. But – by design – progr.es functionality should help make it clear which to choose:

Must steps happen one after another?
If so, you are likely dealing with milestones.
For example: you will need to get a product order before shipping it to the buyer; one must come before the other. This is enforced in progr.es by disabling milestone checking for all milestones apart from the next one due.

Is the sequencing less strict or the step less critical for tracking?  
If so, you are likely dealing with tasks.
For example: if you were building a custom chair, you might already get a customer’s requirements or specifications before the order has been placed. You might group tasks such as cutting wood, assembling pieces and painting together in a “build chair” milestone because  even though, as above, the steps must happen one after another, you are not that interested from a management perspective when each of these happens, but rather that the overall chair is built or not. On the other hand, if you had different teams assembling and painting chairs, then it would definitely make sense to promote these tasks to milestones. Unlike milestones, progr.es allows task checking at any time.

When you build your first projects there will likely be some changes (new milestones or tasks, or edits of existing steps) over time. Ultimately, when you feel like you have really nailed down the steps involved for a project and they will run in the same way repeatedly, this project has become a process - which is just a type of project whose steps have been standardized and formalized.

Having processes should making creating and managing projects much easier for project managers. Once a process has been created all that is required is a couple clicks and a new project is launched. For example, if you have a process for building a chair, you can simply kickoff a chair project by clicking on that process – you don’t have to rethink all the steps and the order in which they must happen again.

 

 

Posted in: Projects