Tips1: Useful Concepts for Organizing Project Timeline (tracks/phases/events)

Project Sprint is based on the concept of goals and milestones to organize the project timeline. In addition to these goals and milestones, this article introduces concepts that team members should know to communicate with each other.

Tracks - the concept when you want to have a multi-linear milestone progression for a goal

Track/Phase Conceptual Diagram

Concept Map of Track

When working on a project with project goals and milestones in Project Sprint, the simplest structure is

• Goal X

  • Milestone A-1 to realize Goal X

  • Milestone A-2 to realize Milestone A-1

  • Milestone A-3 to realize Milestone A-2, Milestones A-3 In a nutshell,

To put it simply in chronological order, this is how the project progresses. Milestone A-3 -> Milestone A-2 -> Milestone A-1 -> Goal X

In reality, however, projects rarely progress in such a simple structure.

For example, in the following case

• Goal X

  • Milestone A and Milestone B are necessary to achieve Goal X

  • Milestone A can be achieved by dividing it into three milestones

  • Milestone B can also be achieved by dividing it into three milestones

In this case, goal X will be realized in the following timeline.

Milestone A-3 -> Milestone A-2 -> Milestone A-1

Milestone B-3 -> Milestone B-2 -> Milestone B-1

Milestone A-1 + Milestone B-1 -> Goal X

The flow of creating Milestone A and Milestone B are called "tracks" respectively.

For example, when considering a project to launch a website (the goal is to complete the website), the team to design the website and the team to set up the system environment for the website will proceed in parallel (though related). At this point, by dividing each work area into "tracks" and separating milestones for each track, we can have a more structured view of the project.

Phases - Semantic positioning between milestones

For example, suppose you have a project with the goal of "launching a new business" and for this you have set the following milestones

• Milestone1: Completion of a research report on the external environment and the situation of the company and its competitors

• Milestone 2: Create a new business plan based on the research document

• Milestone 3: Create an environment in which you can actually launch your business based on the new business plan.

By executing these milestones in order from the top, the goal can be achieved. Milestones need to be tied to deliverables, which is why they are written in this way. (The research document, the new business plan, and the environment in which the business can be launched are each deliverables.

However, in terms of communication in a project, it is better to be able to express what we are doing now. Each of these is called a "phase". So, in this example, the phase can be called as follows,

• Until milestone 1 is achieved: Research phase

• Until milestone 2 is achieved: Planning phase

• Until milestone 3 is achieved: realization phase

It is important that the names of the phases make it easy to understand what you are doing within the overall milestones toward the goal, not only for your own team but also for the other team members in the project.

As a result, you may need to collaborate with other tracks to share progress and check milestones in detail. In this case, the role responsible for the progress will be the one to consider and decide if collaboration is necessary, while the role responsible for the process will be the one to arrange the meeting.

Events - Key events that affect the setting of milestones and goals.

Anything in the project's external environment that project members need to be aware of because it affects the setting of milestones and goals is called an "event" and should be managed separately.

One typical example is the day-to-day business of the organization, which is separate from the project. One typical example is the day-to-day operations of an organization that are separate from the project, such as board meetings. Although these meetings do not themselves produce project deliverables, it is sometimes necessary to set milestones to coincide with these meetings because some kind of report or request for approval is made regarding the project. In other cases, feedback from these meetings may change the assumptions of the project, necessitating changes to the milestones and sometimes even the goals themselves.

It is also useful to manage events with a time frame, such as a "commercial period". The fact that you need to set project milestones accordingly, or adjust milestones or goals as a result, does not change whether it is a specific date or a time period.