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.
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.
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.
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.