Transparency
Find Out How You Can Benefit From Our Approach!
The Project Overview Map Is The Single Source Of Truth
Regardless of your preferred methodology—whether agile, waterfall, or another style—you need written and binding documentation from the project perspective that provides an overview of goals, solution components, requirements, etc., in a clear and consistent format. The Project Overview Map is binding throughout the entire project lifecycle. During this period, it is the single, reliable source of truth. Therefore, it is invaluable for the project’s Leadership Team to engage all stakeholders and ensure consistency, accountability and reliability. All critical decisions in the project are made based on this documentation.
The concrete implementation of the Project Overview Model, whether in a wiki, a website, or a more formal model, depends on the skills and habits of the project team and the specific task.
In contrast, the documentation of individual building blocks is significantly more detailed. For building block-specific documentation, the responsible teams must consider multiple projects and processes. It contains a lot of information that is not relevant to every project. For obvious reasons, project documentation should not be a duplicate of the documentation of multiple building blocks. Documentation of overarching topics such as company-wide data protection or compliance behaves similarly.
The Project Overview Map Connects Stakeholders And Projects
Most projects suffer from weak stakeholder engagement.
The project overview map facilitates two-way communication between projects and their stakeholders. On the one hand, stakeholders define requirements whose fulfillment they want to track. On the other hand, the project formulates what it intends to deliver.
All of these communication flows result in constraints and requirements that the project team must consider in an orderly manner.
However, this can only be achieved if all project participants and stakeholders have a shared understanding of exactly what the project will deliver, how, and when. Therefore, it is important that the format and content of the overview documentation are appropriate for the entire project team and all stakeholders, including sponsors, decision-making bodies, and implementation partners.
-
Project Sponsors
-
Delivery Teams
-
Portfolio Management
-
Architecture Board
-
Security/Data Protection
-
Risk Management
Project Sponsors
Project sponsors promote the idea of a project within the company. They have formal decision-making rights, and provide budget and resources.
Obligations Of Project Sponsors
Sponsors contribute to transparency by providing guidance and direction. This includes formulating the vision, business objectives, and, where appropriate, outlining customer benefits. They also communicate changes in direction, such as when the company strategy or market conditions change.
Value Of The Project Overview Map For Sponsors
Transparency allows sponsors to make fact-based decisions and respond appropriately to uncertainties in project implementation. Project sponsors are informed about the overall progress, including information on resource conflicts, delays, budget concerns, development status of deliverables, and risks that could impact goals.
Collaboration
The sponsors work with the project's leadership team to make the project vision and other information accessible in the Project Overview Map.
The leadership team monitors the implementation of the project goals and documents the progress in the overview map. It reports on progress to a steering committee in which the sponsors and other stakeholders are represented. The leadership team ensures that decisions are well prepared and deviations and changes to the goals or risks are addressed appropriately.
Delivery Teams
Delivery teams take on the core work of a project. They are either established specifically for the project or are existing maintenance teams permanently responsible for a software asset or business concept. In the latter case, multiple projects compete for the team's capacity.
Obligations Of Delivery Teams
As mentioned above, the delivery teams handle the core work of the project. Their contribution to transparency is also multifaceted:
During the scenario assessment phase, the delivery teams participate in the solution design. They also provide initial estimates for resources, timeframe, and costs.
During the implementation phase, the delivery teams report on their progress. They provide relevant details centrally for neighboring teams or link relevant sections of their product documentation to the project model.
Value Of The Project Overview Map For Delivery Teams
The most important added value for delivery teams is that they can rely on the completeness and accuracy of the defined project goals and overarching requirements.
Furthermore, an overview model contains all information about dependencies and interfaces between the deliverables of neighboring teams, as well as the corresponding agreements. Without a centrally maintained truth, interfaces are often no-man's-land and a source of errors and misunderstandings.
Collaboration
During scenario assessment, representatives from the participating teams jointly develop a rough draft of the planned solution and identify dependencies between the building blocks.
During the implementation phase, the delivery teams and the leadership team respond to the ups and downs of project work. This includes regular meetings with the leadership team and, if necessary, with neighboring teams.
While the leadership team coordinates the collaboration of all delivery teams in the project, the delivery teams focus on the requirements assigned to them.
This approach allows the different delivery teams to work using different methodologies, such as Agile or Waterfall. This minimizes dogmatic discussions about methods and allows all teams to work as efficiently as possible.
Portfolio Management
Portfolio management typically maintains an overview of all projects planned or currently underway within the company. The company's available resources, such as budget and staff, are allocated to projects in an orderly process. Portfolio management often also organizes the project approval process, in which decisions are made about new projects.
In particularly well-organized portfolio management, the content-related dependencies between projects are also known – for example, if one project develops a deliverable that is required in a subsequent project. This is especially important when budget or schedule disruptions require portfolio replanning.
Obligations Of Portfolio Management
With portfolio management processes and reports, the risk of overbooking a shared delivery team or system team is mitigated or can be identified early enough to align the priorities of projects that rely on these critical resources.
Value Of The Project Overview Map For Portfolio Management
Portfolio management benefits from the overview map because it provides accurate information such as estimated/expended effort per milestone or delivery dates. In many other projects, this information is far less accurate.
Furthermore, the overview map provides contextual information that is essential for assessing a project.
Collaboration
The leadership team serves as the central contact for portfolio management.
Architecture Board
The Architecture Board is a governance body that must ensure that project solutions conform to the company's target architecture and the standards.
Obligations Of The Architecture Board
The architecture board formulates requirements to ensure that the project creates a sustainable solution that fits into the company's IT technology portfolio and applies the relevant EA standards. These additional requirements must be included in the project overview map or linked there.
Ideally, the architects also actively support the solution design based on the identified requirements.
Value Of The Project Overview Map For The Architecture Board
The architecture board has a reliable channel to communicate its project requirements and monitor implementation progress.
Misunderstandings and laborious remediation can be minimized.
Collaboration
The leadership team involves the enterprise architecture as early as the scenario assessment phase in order to record architecture requirements and guidelines for each scenario. Once the scenarios are defined, the architects are asked to evaluate each scenario.
At the beginning of the implementation, the architects are asked for architectural advice. During implementation, the architects are invited to the system demos to check that the project is on track. This continuous collaboration minimizes the risk of a formal rejection of the project architecture in the architecture committee and the resulting avoidance of transformation architectures saves costs and effort.
Security / Data Protection
The exact organizational structure of security and data protection varies from company to company. Often, some tasks are located in the legal department. Or technical and business issues are organizationally separated. In other organizations, these topics are part of the architecture.
But regardless of the organizational structure, it must be ensured that a company's data and functions are protected from unauthorized access. The organization for security and data protection ensures the protection of critical information, infrastructures and technologies. It monitors and reports critical problems and develops security strategies and plans to prevent disasters and restore the IT landscape. Security relevant legal changes and innovations are evaluated, dealt with and trained.
Obligations Of Security And Data Protection
The security and data protection team provides guidance and feedback on the solution design. The completeness and appropriateness of the security requirements and controls must be assessed. Additional requirements must be formulated if necessary.
Similar to the architecture committee, it formulates general requirements to ensure that the project creates a solution that fits into the company's security strategy. These additional requirements must be included in the project overview or linked there.
Value Of The Project Overview Map For Security And Data Protection
The project overview map provides clarity about the overall solution, allowing the security and data protection team, who are not involved in the day-to-day operations of the project, to identify the aspects of the project that are relevant to them. The leadership team also provides them with a point of contact for questions and concerns.
This approach increases transparency about key risks and their mitigation, thereby leading to better defense against damage to the company – be it financial or reputational.
Collaboration
The leadership team typically collaborates with the security and data protection team during the implementation phase to ensure that all relevant requirements are met by the project.
In some cases where security could impact the project's scope and budget, engagement must begin during the scenario assessment.
Risk Management
Risk management identifies, analyzes, assesses, and monitors risks that could cause significant damage or even threaten the company's continued existence, and takes measures to avoid, mitigate, or shift identified risks. It develops strategies to maintain a balance between risks and benefits.
This often includes the success of major projects if they are critical to competitiveness or are legally indispensable.
Obligations Of Risk Management
Analysis of the project scope and assessment of which risks are monitored centrally and which are monitored by the project. The measures are evaluated to determine whether they are sufficient to achieve the desired goal.
Value Of The Project Overview Map For Risk Management
The project overview map enables traceability from the risk through the measures to the specific activities. This means that risk management always has an overview of who is working on which risk.
The leadership team servers as the single point of contact.
Collaboration
During the scenario assessment phase, the leadership team presents the scenarios to the risk management team and supports the analysis. It explains the project overview map and prepares the necessary reports to enable appropriate risk management.
In the implementation phase, the leadership team holds regular meetings with risk management, if the project's risk profile requires strict control, and prepares the necessary reports.
The Project Overview Map Ensures Consistency Throughout The Whole Life Cycle
You’ve probably experienced this before: A project has a promising business case but delivers something completely different. The budget is exhausted, but the original goal isn’t achieved.
The project overview map that transparently tracks the goals throughout all project phases helps you keep track of where you stand. It enables the documentation of all important project decisions and their linkage to the goals. Maintaining an overview throughout all phases is particularly crucial in a heterogeneous, geographically and culturally diverse project. In such complex environments, knowledge, plans and intentions seem to decay particularly quickly from one day to the next. This is especially true for product-oriented or agile organizations and complex supply chains. The resulting transparency forms the basis for the sponsors’ and delivery units’ ability to act, as well as for fact-based decisions.
Inception Phase
During the inception phase, the project objectives are defined. These primarily include corporate objectives such as profit or reputation and their relationship to the corporate strategy. Except for purely technical or legally motivated projects, customer benefits are also a priority from the very beginning.
Key Stakeholders
The project sponsors work with the designated leadership team of the project. If necessary, key suppliers or the architecture board are involved in the early stages to develop the vision for the solution.
Methodology And Results
The inception phase typically has an informal character. It provides a description of the goals and a rough idea of what a solution should look like.
Although the process is still largely informal, all stakeholders who are expected to contribute to or be affected by the project should be informed of the plans right from the start.
At its end the sponsors free an initial budget for the development of the business case.
Scenario Assessment Phase
The goal of the scenario assessment is to outline one or more options for a project and select the preferred variant. A business case must be developed for this variant, and an investment decision must be made.
Typically, the two or three most advantageous scenarios of the project are analyzed in detail, including the pros and cons, risks, estimated costs, etc. For this purpose, the objectives are broken down into broad deliverables and the dependencies between deliverables are documented. A virtual implementation organization is designed and a high-level milestone plan is developed. Finally, a cost-benefit analysis is prepared together with the relevant representatives of the future delivery organization.
Key Stakeholders
During this phase, the project sponsors and representatives of the delivery teams are most active. They work together with the project's leadership team to analyze the various scenarios.
The leadership team involves all other stakeholders, including architecture, portfolio management, risk, and data protection&security, to gather their input for the scenario analysis.
At the end of the phase, the investment board, which is often located within portfolio management, makes a decision about the project.
Methodology And Results
Various methods – moderated by the leadership team – can be used to analyze and outline scenarios. Above all, results and work packages must be derived from the original project objectives. This can be done using decomposition techniques such as Modeling4Digital.
Once we have an overview of the results, the respective work packages and estimates must be created. In most cases, T-Shirt-Size estimating is sufficient. More precise estimates can be made later in the implementation once more insights are available.
Based on the analysis, scenarios can be documented using, for example, the Business Model Canvas technique.
Finally, the official portfolio management templates should be used for scenario decisions and business case documentation.
Implementation Phase
The purpose of the implementation phase is to produce the deliverables required to achieve the project goals while adhering to specific constraints such as delivery time or budget.
The delivery of a typical project is achieved through sequential and parallel work packages with multiple dependencies. Various, potentially very different, delivery teams are involved. For this reason, in addition to the actual deliverables, documentation must also be created that enables successful navigation through the network of work packages, Tracking progress, and the orchestration the work of different teams.
Key Stakeholders
The leadership team coordinates the collaboration of all project participants. This includes presenting results to committees and boards, obtaining approvals, and coordinating work packages. The leadership team maintains the project overview map, which forms the basis for all communication. It represents both the specific perspective of each stakeholder and the overall context.
Above all, the delivery teams must deliver the planned deliverables.
The sponsors track overall progress and communicate any changes to project objectives.
Portfolio management, architecture, risk, and data protection & security conduct specified reviews to ensure the project is on track.
Methodology And Results
The teams use their familiar and proven working model (agile, hybrid, or waterfall) to achieve the agreed-upon results. The leadership team uses regular ceremonies to track progress and keep the project overview up-to-date and consistent.
At the beginning of the implementation phase, the agreed scenario is specified in detail by expanding the existing project overview map, adhering to the decisions made during the assessment of the agreed scenario. Furthermore, all results of the implementation phase, such as detailed requirements, deliverables, etc., must be traced back to the original requirements that led to the decision for this scenario.
As existing processes or systems are further developed, the details will naturally be worked out within the respective teams. A reference to the overarching specification can then be found in the project overview map. However, it is important that the project always has a consistent high-level model with branches at all levels of detail, and that the teams involved are aware of their role in implementing this model.
After the delivery of each work package, the sponsor has the opportunity to change or reprioritize the project goals.
Transition Phase
The purpose of the transition is the smooth handover of the project results to permanent operation.
A reduced project team supports the maintenance teams for an agreed period of time. The operating teams are trained, processes are introduced, and product documentation is adapted based on the project overview map. The project closure report, presentations, and other formally required artifacts are created.
The project organization is being dissolved step by step.
Key Stakeholders
The operating teams assume responsibility from the delivery teams.
The leadership team moderates this process.
The project sponsor officially closes the project.
Methodology And Results
The transition must be conducted according to the specific procedures of the maintenance organization.
We Have The Experience To Make Transparency Look Easy
There is no one-size-fits-all solution for a Project Overview Map. It requires considering the skills and background of the people involved and the specific task at hand. Using your own proven techniques, such as modeling tools or wikis, reduces the learning curve.
The problem with project documentation is often that it’s well-intentioned but mutates into a bureaucratic monster that’s of no use for day-to-day work and becomes outdated faster than it can be updated. Least of all, it allows for informed management decisions—a primary purpose for which it was created.
With SOAPARK, you don’t start from scratch. Instead, we have years of experience and a metamodel based on 13 domains that we use as the foundation for your specific implementation. While the raw model may seem intimidating, once you’ve identified the most important parts for your individual case and added your content, it becomes a source of clarity and inspiration.
Simplicity is crucial so everyone can benefit.
Why
The “why questions” reflect the motivation for the project. They are discussed at the beginning of the project.
Vision
Description
The “Vision” section provides the most compact and concise project description. It summarizes the value the project offers to customers and the company.
Vision statements are frequently found on project manifesto posters for good reason. They provide easy-to-understand guidance and ensure that all stakeholders have a consistent understanding of the project content.
Life Cycle
Initial vision statements are developed in the inception phase. They are supplemented in the subsequent scenario assessment phase and agreed upon with all key stakeholders shortly before the project is approved and company funds are spent on implementation.
During implementation, all project decisions are continuously reviewed against the original vision statements, and the results are measured against them. To achieve this, the most important requirements for success are translated into clear and easily trackable KPIs.
Changes to the vision represent a significant realignment of the project that must be agreed upon with stakeholders.
Customer Value
Description
The domain “Customer Value” answers the question of why this project is being undertaken from the customer’s perspective. This goes hand in hand with the business case, which answers the related question of why the project is being carried out from the company’s perspective.
Life Cycle
Except for purely technical optimization projects, the discussion of the customer value is at the beginning of a project in the inception phase. It is the central motivation for the project and should remain largely constant throughout all project phases.
Typically, personas and customer segments are outlined in the scenario analysis and fully developed during implementation. However, if the business case critically depends on specific customer segments and personas, how they are addressed, or how they react to the project outcomes, these must be fully developed prior to implementation.
Business Case
Description
The business case for a project consists of the benefits for the company and the associated costs. A distinction is made between ongoing costs (operating costs) and one-time costs (investments). When deciding on a project, various scenarios with different benefit profiles are typically considered – e.g., high benefits with high investments and lower benefits with lower investments.
Life Cycle
The business case is developed as the result of the scenario assessment phase. It is linked, on the one hand, to the expected values for the company and customers, and, on the other hand, to the project’s outcome—i.e., the deliverables with their associated costs, and schedule.
During the implementation phase, the project delivers its results. If assumptions regarding the costs of a deliverable or the schedule need to be adjusted, the business case must also be adjusted. Therefore, traceability of the key success factors is of utmost importance for project success and is monitored throughout implementation.
What
The “what questions” reveal what the project ultimately delivers from both a business and technological perspective. They clarify the key building blocks and their integration.
Requirements
Description
The “Requirements” section describes the most important constraints and requirements for a project as a whole. In particular, it formulates those central requirements whose non-fulfillment would lead to dealbreakers—i.e., the failure of the project. Detailed requirements, e.g., for individual project steps, are processed and recorded separately in the individual teams.
Life Cycle
Requirements are captured throughout the project life cycle as knowledge about the topic grows. However, important requirements that have a significant impact on the structure of the solution must be known before the implementation phase begins.
However, it may happen that project areas cannot be clearly defined until well into the implementation phase. This uncertainty should be explicitly addressed in the solution development process—for example, by using exploratory techniques such as design thinking.
Avoid treating all areas of the project equally out of convenience. Where a high degree of certainty exists, solid planning should be used, while exploratory approaches should be taken in areas of uncertainty.
Business Solution
Description
In the “Business Solution” section, we describe use cases, processes, business objects, capabilities, and functions. Not all of these abstractions are relevant to all projects. Instead, we consider those that best fit the nature of a project.
A “business solution” can be described in any depth, and this is often necessary—for example, when introducing a completely new process, every single step must be worked out. However, this is not the scope of an overview model; instead, we focus on those facts that are relevant to project management and the solution’s architecture.
Life Cycle
The rough overview of the business solution is developed in the scenario assessment phase in order to derive all solution components and estimates. This can be achieved, for example, by focusing on use cases (or similarly, on business events, or business services). Techniques such as functional decomposition or domain storytelling or event storming can help you create a complete overview of your project. However, details are omitted during this phase.
Implementation is often organized into releases with multiple interim deliveries within each release, for example, in the form of agile sprints. To plan each release, the relevant part of the overview model is further broken down into finer parts to form the basis for development planning.
Applications
Description
The “Application” section contains software systems and their sub components such as applications, application components, data objects, and interfaces.
Typically, all of these elements are included in enterprise-wide architecture documentation. If this is the case, only core data and a reference to it are required. Even if a project introduces a new application, the enterprise architects should include it in their documentation.
The elements in the applications section are linked to elements of the business solution, for example, to indicate which new features they should receive or which features are used by a project.
They are linked to the elements of the infrastructure section to indicate how they are physically implemented.
Life Cycle
The list of required applications is developed in the scenario assessment. This is necessary to involve the respective application owners in the cost estimates and verification of the overall solution concept.
Interfaces and data are designed as part of the release planning during the implementation phase.
Infrastructure
Description
The Infrastructure section describes the physical runtime for the application layer elements of a project, including compute nodes, storage, and networking.
Life Cycle
Unless infrastructure is the main focus of the project, only a very rough outline and a cost estimate are required in the scenario assessment.
The detailed design takes place during implementation, as only then is sufficient information available for a good design, especially for appropriate sizing.
How
The “how questions” describe project execution from a project management perspective. Delivery teams also answer “how questions”, but they typically relate to process details and technology and are not considered here.
Roadmap & Milestones
Description
The “Roadmap & Milestones” section structures the project activities and their dependencies.
A large project typically includes multiple roadmaps, each with interdependent milestones. For example, one roadmap covers the step-by-step development of a software solution, while a second roadmap describes the rollout of a process across different parts of the organisation that leverages the new software solution. The milestones of both roadmaps are closely linked.
Work packages related to deliverables are usually linked to the milestones.
Life Cycle
Roadmaps, milestones, and work packages are outlined early in the scenario assessment. This is a useful activity even at this early stage, as it encourages the responsible teams to analyse the project’s feasibility in more depth.
In the scenario assessment, the work packages are estimated using T-shirt sizes. These estimates are refined and hopefully verified in the planning cycles of the implementation phase.
It should also be taken into account that new insights and external events will regularly require replanning during the course of the project.
Estimates
Description
Cost estimates are typically assigned to work packages. Work packages, in turn, refer to a deliverable planned for a specific milestone.
We distinguish between two types of estimates:
1. Regular estimates, in which an estimation team explicitly formulates the constraints of the estimate, specifies the estimation method, and provides a value in euros or person-days.
2. T-Shirt-Sizes: These are estimates that are submitted either for very small work packages or at an early stage when the exact requirements are not yet known. T-Shirt-Sizes are often submitted by small teams or their managers. A sophisticated methodology is not required.
Life Cycle
In the scenario assessment, T-Shirt-Sizes are first determined. The project is then approved based on these. The T-Shirt-Sizes are step-by-step converted into proper estimates during implementation.
The same procedure is generally followed with external suppliers. However, it is recommended to develop proper estimates as soon as possible and, if necessary, to plan for further decisions and negotiations.
Controlling
Description
Setting up project controlling is a highly individual matter. The right controls depend on the content and goals of the project as well as on the way the project works and the company’s practices.
Controls can include planned tests, KPIs, and costs.
Care should be taken to ensure that only the most necessary controls are installed to minimize overhead and bureaucracy.
Life Cycle
Controls are defined in the scenario assessment to track the achievement of project goals.
The concrete evaluation of the controls takes place during implementation.
Risk
Description
From the very beginning, we repeatedly run through scenarios that could cause the project to fail and identify all possible risks. In particular, we analyze the impact of a risk on assumptions underlying the business case (e.g., the target customer group is smaller than expected) or on deliverables (e.g., a feature cannot be implemented at the planned cost).
Life Cycle
Risk analysis ist most important at the very beginning of a project. Latest in the scenario assessment the analysis of the potential impact of risks on the business case is essential. Just as in solution design, where we take imaginary journeys into the future to envision the solution, it is equally necessary to explore all possible failure scenarios. To do this, we use techniques such as pre-mortem analyses.
During implementation, the potential risks become a daily companion in ongoing design and review sessions with all stakeholders.
KPIs
Description
KPIs are a great tool to measure the progress of the implementation and the fulfillment of the business case. Here, “less is more” applies, and we focus on only a very few KPIs that are directly linked to the project’s most important success factors.
Alternatively, OKRs can be used, depending on what best suits the project and what the people involved have the most experience with.
Life Cycle
KPIs are defined in the scenario assessment and tracked through well-organized controls during implementation.
Who
The “who questions” revolve around the people who actually deliver the project, benefit from it, or are affected by it.
Key Actors
Description
Key actors include stakeholders with decision-making rights or delivery obligations in the projects as well as suppliers, supporters or important customers.
The section provides a list of all important people and companies with their role and contact details.
Life Cycle
The list of key actors is maintained throughout the whole life cycle.
