Designing a stage model

Define the different phases or stages that a project will go through from initiation to completion. This typically includes stages like idea or proposal, planning, active, closing, and archiving. The number and nature of stages may vary depending on the organization and the specific project requirements. It may also be helpful at this stage to consider which phases should be eligible as stating phases, which phases are standard phases which can be transitioned in and out of, and which phase is the end phase of the model. The phases that are being defined will need to be created as stages and then be implemented as part of a stage model inside WorkPoint 365. Additionally, Identify the key deliverables and milestones that mark the completion of each stage. Try to clearly define the expected outputs, outcomes, and achievements for each stage. This is not strictly necessary in order to implement stage models in WorkPoint 365, but can helps in tracking progress and ensuring that the project is on the right track in practice.

Some key questions you could ask yourself are:

• Which phases should be possible for my projects to go through during their life cycles?
• What are some short, concise names for the phases I have defined?
• Which transitions between phases should be possible? Are there some that should be locked behind certain constraints, or perhaps completely prohibited?

WorkPoint offers many ways of automating the execution of jobs upon sage changes. The examples are many, but some could be changing the welcome page of a project when starting a specific stage, creating a set of tasks when a specific project is started, or sending an e-mail to project team members when their project goes active.

When designing a stage model, it can be beneficial to also consider if you want to take advantage of some of the automation options provided by WorkPoint.

Some questions you could ask yourself in this context:

• Could it be an idea to change the welcome page of projects when a specific stage is active?
• Should we send e-mails and/or notifications out automatically when a project changes stage?
• Do we have stage-specific tasks for projects, and could it be an idea to automatically generate these tasks on the project when the relevant stage becomes active?

Permission management can be used on various different ways in relation to stage management and stage models.

One way is to restrict access to a project dependent on which stage the project is currently in. For example, it is possible to define rules such that only the project manager and project assistant have access to the project site when the project is in an Idea or Planning phase. Access could be granted to the project team upon changing the stage of the project to a later stage when the project goes live.

It is also possible to use permissions to define which personnel should be able to change the stage of a project. This can e.g., be beneficial to ensure that stages are only changed by people who have direct responsibility for the project.

When thinking about permissions in relation to stage models, you may ask yourself:

• Should access to project sites be dependent on and change in relation to the current stage of the project?
• Who should be able to change the stage of projects?

In WorkPoint 365, it is possible to define multiple stage models on the same business module. An example of use could be to have a stage model for large projects, and another one for small projects. The large project stage model could be very complex, utilizing all defined stages and multiple constraints to  ensure compliance and effectiveness. The small project stage model could be used for projects that only require a subset of the defined stages and with fewer constraints and a transition options.

Some key questions you could ask yourself are:

• Does the solution work with multiple different types or sizes of projects which could benefit from differentiated stage models?
• What is the characteristic I want to differentiate projects based on? Is it the project size, the project type, or a third aspect?
• Should projects be able to transition from one stage model to another, if e.g., a project evolves from being a small project to a large project?

The sub-stages feature allows you to define sub-stages for each stage. An example could be to break up the "Analysis" stage up into sub-stages, e.g. "Data collection" "Risk analysis", etc. These substages help provide a more granular view of the project's progress and enable project managers to effectively manage and control the project's activities within each stage. The specific substages may vary depending on the project's nature, industry, and the project management methodology being used.

Questions to consider:

• What are the key activities or tasks that need to be accomplished within each substage, and is it better to have these implemented as substages or as tasks on the project?
• How do these substages contribute to the overall progress and success of the project?
• Are there any dependencies or sequencing requirements among the substages within each stage?
• How can the substages be effectively tracked and monitored to ensure timely completion?
• Are there any specific deliverables or milestones associated with each substage that need to be defined?