ºÚÁÏÍø

Following criteria should be considered when evaluating whether a development initiative can be considered a development project (and should follow the Aalto Gate Model):

1. If development funding is requested from Strategic Steering Group, the initiative is always considered a development project
2. Budget exceeds 50k€
3. Affects & involves multiple functions
4. Internal workload is significant (+100 MD/HTP)
5. A temporary development endeavor with a definite beginning and end. Aiming to establish something new or improve existing operations, not just to keep operative business running.

• Major Project: &²µ³Ù;300°ì€
• Full Project Governance​: G1, G2, G3 & G5 brought to Strategic SG for decision-making, G4 & G6 informed (unless additional funding requests or agreed otherwise)
• Project Steering: Always named Project Owner and Project Steering Group

• Medium Project: 50°ì€-300°ì€
• Medium Project Governance: G1, G3 & G5 brought to Strategic SG, rest informed (unless additional funding requests or agreed otherwise)

• Project Steering: Always named Project Owner & usually Project Steering Group (not always mandatory)

• Light Project: &±ô³Ù;50°ì€
• Light Project Governance: Only G1 & G3 brought to Strategic SG, rest informed (unless additional funding requests or agreed otherwise)

• Project Steering: Project Owner sufficient, sometimes light project steering group​ is named

Project Book is an early-stage description of the project proposal/idea, and it is used for project prioritization. It should be filled with the best available information and estimates to showcase the project's value and reasoning for getting development funding.

Project impact scoring is done during project prioritization process by utilizing the project prioritization model. The impact scoring helps Strategic Steering Groups in understanding and assessing the impact of projects, in a generalized and comparable way. The Weighted Scoring Model is composed of different aspects of impact but also includes evaluation of risk level and whether the project is a "must do".

Gate-form should be filled for G2 and G3 decisions with updated project information and sent to the SG coordinator before the SG meeting.

Pre-study is a crucial step to investigate a project's viability, key requirements, and different options. It's an analysis of the current situation and potential solutions, acting as a low-risk, high-value foundation for informed decision-making.

Project has objectives and it is important to understand the functional and possible technical requirements to reach those objectives. Understanding the key requirements and end-user needs is the prerequisite for finding the best solutions. Not all requirements are equally important, and that’s why they should be prioritized (the prioritization of requirements continues throughout the project based on learning and gaining more information). At this stage, it can be hard to define all technical requirements due to lack of information related to technical solutions, but these should be included based on best understanding and expanded later. 

Project scope defines the boundaries of the project; detailing its specific goals, deliverables and constraints, basically outlining everything included (and excluded) in the project. It sets the boundaries and criteria for successful project completion and creates a shared understanding and expectations.

If project scope is not clearly defined or protected during the project, the focus may be lost. Such situations are called "scope creep", which refers to uncontrolled expansion of the project scope, often leading to delays, budget overruns, and quality issues.

Sometimes it is beneficial to investigate and provide multiple alternative scopes, as they can each be justified based on different conditions or constraints.

Project steering group should be formed and agree on resourcing (project team, other specialists) with relevant managers. 

It is recommended to have a kick-off meeting and agree on ways of working.

Estimate the initial project budget and workload based on the information gathered during preparation and pre-study. 

The first budget estimate is documented in the Project Book, so you can get back to it if needed.

Architecture approval is part of the Aalto University's compliance principles and the official investment lifecycle model. In architecture approval and related assessments, the project's impact and suitability for Aalto's environment and future plans are ensured. Enterprise Architecture approval is documented in Thinking Portfolio. Contact EA to get EA approval: it-arkkitehtuuri(at)aalto.fi.

For more information, please see the Enterprise architecture services in Aalto page.

Every development project should be opened in Thinking Portfolio tool. Send service request to servicedesk@aalto.fi to open up the project in Thinking Portfolio and attach your Project Book / Gate Form to the request. Once the project is added to the tool, Project Manager should keep the project information updated (incl. status reporting).

Project plan is a detailed plan to execute the project, and it should be actionable and realistic. Some of the main contents include: 

• Detailed timeline: includes milestones, dependencies, and deadlines (often using Gantt charts).
• Work Breakdown Structure: decompose major deliverables into smaller, manageable tasks.
• Budget & resource allocation: estimate costs and allocate funds, assign people to tasks.
• Risk Management: identify potential risks, assess their impact, and create mitigation strategies
• Communication plan: define channels, frequency, and stakeholders for communication.

Solution design/architecture should be defined for IT projects, also known as High-Level Design or HLD. It provides a bird’s eye view of the system once the implementation is completed. A high-level solution architecture diagram is required, and it includes the key components of a system such as platforms, applications, interfaces, interactions, and the overall data flow within the system

Tip: If you are unsure how to do this task, you can utilize AI. Describe your project and known integrations, data flows and basic logic, and ask the AI to generate "High-level solution architecture diagram".

Create a high-level testing plan, that describes:

• Testing goals
• List features to be tested and excluded (High-level, expand/update during implementation)
• Testing types, methodologies & tools (e.g., performance, security) to be used
• Deliverables (e.g., test cases, reports)
• Timelines & roles

Update the initial budget and work-load estimates created in the previous phase and add any additional details gathered, such as license costs or workload changes.

Digital compliance approval (previously known as security approval) process must be completed before an IT system, digital service or license can be used for teaching or work at the university. This also applies to free licenses and services and services that are not maintained by Aalto University.

Digital compliance for G3 / G4 are requested via eSupport → â†’ Project security approvals. If the required technical information cannot be provided at G3 (not known yet at this stage of the project), the technical review should be conducted before G4. Security approval is documented in Thinking Portfolio.

More info about project security approvals can be found here. 

G3 enterprise architecture assessment looks at the suitability of a system or application for the Aalto University's existing environment and target architecture. Enterprise Architecture approval is documented in Thinking Portfolio. Contact EA to get EA approval: it-arkkitehtuuri(at)aalto.fi.

For more information, please see the Enterprise architecture services in Aalto page.

Before rollout / go-live, the Project Steering Group must approve the project deliverables and that the agreed requirements and scope is achieved.

Initial project documentation related to the project outcomes, such as process description, technical documentation and operating manual.

When testing is completed, a testing report ought to be produced and accepted by the project steering group.

Before rollout / go-live, maintenance and support model should be discussed with relevant process or solution owner. 

Digital compliance approval (previously known as security approval) should be requested before rollout / go-live, to ensure that all relevant compliance aspects have been taken into account for safe deployment. Digital compliance approvals for G3 / G4 are requested and in eSupport  â†’  â†’ Project security approvals. More info about project security approvals can be found here.

Finalize and expand the initial documentation created earlier. Additionally, update the project budget and workload actuals, document lessons learned.

• Discuss the storing of project outcome documentation (process description, technical documentation and operating manual) with relevant process / solution owner.
• Project Lessons learned & closing report should be uploaded to Thinking Portfolio.
• Project-specific materials/documents should be kept in project teams for 1 year.

Before closing the project, agree and finalize the handover to relevant service organization. 

Gather feedback and lessons learned before closing the project and releasing the project resources from their duties.

Fill the project closing & lessons learned report including:

• Project results: how did the project go? Did you achieve the project goals? Did you stay within planned timeline, budget and scope?
• Budget & workload actuals: Compare estimates vs. actuals
• Lessons learned: What did you learn during the project?
• Plan for post-project business value evaluation: Agree on post-project business value evaluation timeline, metrics, responsibility & documentation. This evaluation concerns Major (A) and Medium (B) projects, is done 1 year after project closure and project owner is responsible that this occurs. Strategic SG is informed about the evaluation results.

Discuss with relevant solution owner about adding the application or solution to CMDB (if applicable for your project).

Project owner is responsible that the post-project business value evaluation is conducted and reported. The evaluation results should be sent to relevant SG coordinator.