Guide to solving the case study

Assignment: Review the general scenario provided, which contains a portfolio of potential projects. Select one project from this portfolio and complete the preliminary project work, the project charter, and the project management plan according to the following instructions. Ensure that all specified elements and content are fully considered and that they are addressed in the given order.
Resources: Online course, coach, flipbooks, general scenario, sample solution from the example project, following guidelines, and templates.

General Guidelines

Personas: When working on your assignments, please create personas that relate to the specific problem or business opportunity you are addressing. These personas should reflect the interests and perspectives of various stakeholders in the different situations of your case study. Refer to the personas at the organizational level of the general scenario or to the personas as defined in the sample solution of the example project.

Please consider the following project roles:

These individuals may be involved in defining, developing, implementing, or using the solution, or may be affected by its outcomes.

Studies: As part of your case study work, it may be necessary to use certain study results to establish the foundation for your project work. Since this is an exercise, please create plausible, fictitious results that still appear realistic. Pay attention to the following:

• Plausibility and Fiction: Create plausible, fictitious results based on realistic assumptions and the data provided in the scenario or your case study.
• Integration and Coherence: These results should be coherently integrated into the scenario and correspond to results that could realistically be expected. They should credibly support the scenario and provide a solid foundation for subsequent project work.
• Example Studies: Here are some examples of possible study results that can serve as models for you:
• Production Analysis: “An internal analysis has shown that our production costs per unit are 15% above the industry average. While leading competitors can reduce their costs to 50 euros per unit, our average costs are 57.50 euros per unit.”
• Customer Survey: “A survey of our key customers revealed that 70% of respondents are dissatisfied with the current delivery times. In comparison, 90% of our competitors have an average delivery time of less than 48 hours.”
• Market Research: “A recent market study has shown that the demand for electric vehicle components is expected to grow by 30% annually over the next five years, while demand for traditional internal combustion engines is expected to decline by 5% per year.”
• Error Analysis: “Our quality control department has found that the error rate in production is currently 3%, while the industry average is 1.5%. The best companies achieve error rates below 1%.”
• Competitor Analysis: “A competitive analysis has shown that our main competitor has increased its market share by 10% over the past two years, while our company has seen a 5% decline over the same period.”

Objective: The objective is to create a convincing and well-founded basis on which the project can be further developed, without relying on actual external studies or analyses.

Creative Freedom in Crafting Your Case Study

Normal Case: Most of the projects listed in the portfolio can be resolved directly within the context of the provided general scenario. These projects align closely with existing needs, current technological trends, and market realities, making it straightforward to define a project charter and plan without further adaptation.

Beyond the Scenario – Embrace “Time Travelling & Magic Stick”: However, for some projects, it might be necessary or advantageous to create a derivative scenario that better aligns with the project’s unique requirements or your personalized case study resolution. As shown in the template case study AutoTech North American Market Entry Strategy, you may find that extending and adapting the scenario creatively using “Time Travelling” and “Magic Stick” techniques can enhance your case study.

Time Travelling & Magic Stick: Imagine how the company might evolve in the future—new product lines, expanded markets, changes in technology, changes in personas, changes in legislation, or any other new fictive reality—that justify your personalized resolution of the case study. In your personalized case study, you can pretend that a certain amount of time has elapsed since the original portfolio or program was created in the general scenario. In this fictive future, explain how things have evolved, establishing a new base for your case study while still leveraging the general scenario, including personas, so you do not have to create the entire background from scratch. Additionally, you can introduce new realities or shifts in the business landscape that enable you to craft a richer and more multifaceted scenario.

There are no limits to your imagination. You have the power to create any fictive reality needed for your personalized case study resolution. These tools are meant to help you craft a derivative scenario that aligns the general scenario with your unique preferences and needs, enabling you to develop an engaging project charter and project management plan. Don’t hesitate to step beyond the original constraints. Be imaginative, but ensure that your scenario remains coherent and aligned with the company’s strategic goals, or new strategic goals you may establish in a derivative fictive reality created by you.

Preliminary Project Work

Form a workgroup. As a group, carefully review the general scenario provided, which contains a portfolio of potential projects. Select one project from this portfolio that your group will focus on for the remainder of the case study.

Begin with a thorough analysis of the scenario, taking into account the problem situation or the business opportunities presented, as well as the organization’s goals and strategies.

• If you are focusing on solving a problem, identify the root causes by asking “Why” questions, and analyze which of these causes are most important or most likely to be addressed by your individual project as part of the case study solution. Also, determine whether certain impacts of the problem should be mitigated within the scope of your project.
• If your focus is on exploiting a business opportunity, identify and analyze different segments or facets of the opportunity, and assess which are most important or most suitable for the case study solution through an individual project.

Ensure that the chosen scope is manageable for a single project.

Determine which other parts or aspects of the problem or business opportunity your project will not address, and document this.

Artefact: Preliminary Project Work Report

1. Names and Student ID Numbers of the Authors: Use the format Firstname LASTNAME (000000).
2. Scenario Title and Summary: State the title of the scenario and provide a brief summary of the scenario provided by the instructor.
3. Chosen Focus Area: Specify the specific problem or business opportunity your group has decided to focus on within the scenario.
4. Scenario Analysis: Describe the results of your scenario analysis, including the identification of root causes (for problem-focused projects) or key segments (for opportunity-focused projects). Discuss how the scenario aligns with organizational goals. Also, determine whether certain impacts of the problem should be mitigated within the scope of your project.
5. Preliminary Scope Definition: Outline the preliminary scope of your project by stating what aspects of the problem or opportunity will be addressed (inclusions) and what will be deliberately left out (exclusions).
6. Study Results (if applicable): Include any fictitious, plausible study results that were created to support your project preparation.

Artefact: Project Charter

1. Names and matriculation numbers of the authors: Use the format Firstname LASTNAME (000000).
2. Project name: The title or name of the project, which serves as its primary identifier.
3. Problem/Opportunity Statement: A description of the specific problem or opportunity that the project aims to address, including its causes and effects or aspects to be and not to be addressed by the project.
4. Purpose Statement: The reason for undertaking the project, addressing a specific problem or opportunity.
5. Goal Statement: A specific statement of what the project intends to achieve.
6. Outcome Statement: The immediate impact or change resulting from the key deliverable.
7. Benefits Statement: The long-term value or advantage gained from the project outcomes.
8. Strategic Alignment and, if applicable, Program Affiliation: This section should describe which organizational goals this project contributes to and, if applicable, to which program this project belongs.
9. Business Requirements: Capabilities the organization wants to achieve via the project for its stakeholders, such as managers, employees, customers, and suppliers. Define user stories from personas.
10. Selected Strategy to Achieve the Project Goal and Rationale for the Selection: The chosen course of action for achieving the project’s goal, including the alternatives considered and the justification for why the selected strategy is better. There is always more than one option to achieve a goal.
11. High-Level Milestone Schedule or General Roadmap: A timeline that outlines the major phases and/or milestones, or a general roadmap of the project, providing an overview of possible progress. These options represent degrees of uncertainty depending on how much pre-project work was done.
12. Key Deliverable and Its Major Components: The primary product, service, or capability produced by the project, along with its main parts or aspects.
13. Inclusions and Exclusions: Specific items, features, organizations or work that will be included in the project scope, as well as those that will be excluded, to set clear boundaries for what the project will and will not cover. This helps to clarify grey areas and manage expectations regarding deliverables and boundaries of the project.
14. Project Success Criteria: The criteria that will be used to determine whether the project has been successful. This project will be considered successful if it meets the following criteria: define those specific criteria.
15. High-Level Risks: A list of potential events or conditions that could negatively impact the project.
16. Assumptions: Statements taken to be true for the purpose of planning and executing the project.
17. Constraints: Explicit restrictions established by key stakeholders regarding time, funds, resources, technology, or other considerations that the project must comply with. It does not refer to the project budget and schedule, which are always constraints in any project.
18. Financial Resources Reserved: This section acknowledges any preallocated funds for the project, based on the business case or portfolio management decisions. It does not establish or imply a project budget, which will be developed during the project planning process. This section is purely informational and does not influence project definition. If corporate has set a financial limit, it should be recorded under “Constraints,” and this section should state “none” to avoid confusion.
19. Organigram of the Project: A visual representation or a textual description of the hierarchical structure to be used to manage reporting relationships between the different leading persons in their specific project roles, showing levels such as project governance, project management, and work package execution (if already visible or known), including their respective levels of authority.
20. Stakeholder Register with Analyzed Stakeholders: A table or matrix listing major stakeholders involved in or impacted by the project, along with an analysis of their importance for the project’s success combined with their current level of engagement.

Artefact: Project Management Plan

1. Names and matriculation numbers of the authors: Use the format Firstname LASTNAME (000000).
2. SMART Objectives Leading to the Goal: Specific, Measurable, Achievable, Relevant, and Time-bound objectives that guide the project towards achieving its goal.
3. Development Approach and Lifecycle: The methodology to be used, such as Agile, Waterfall, or a hybrid approach, and the phases the project will go through from start to finish.
4. Requirements and Quality Attributes: Transpose business requirements from the Charter. Gather functional requirements and quality attributes for the solution. Classify all according to the MoSCoW method as Must-be, Should-be, Could-be, and Won’t-be to guide the development team on the essential functionalities and quality metrics of the solution and to clarify which business requirements will be fulfilled with this project.
5. Scope Statement: A document that defines the project’s scope in two main areas:
   • Product Scope: A description of the product and its components, detailing what the product will look like, its features, and its functionalities.
   • Project Scope: The work that needs to be done to create the product.
   • This section also includes exclusions, updated assumptions, and constraints.
6. Product-Oriented and Actionable Work Breakdown Structure (WBS): Both structures use a hierarchical numbering system to detail all parts of the project, for example: 1, 1.1, 1.2, 2, 2.1, 2.2, etc.
   • Product-Oriented WBS: The Product-Oriented WBS (PO-WBS) provides a detailed breakdown of the Key Deliverable into its components and subcomponents. This structure focuses on the final product and outcome, ensuring that all essential parts are fully accounted for and understood, without addressing the execution sequence.
   • Actionable WBS: The Actionable WBS (A-WBS) builds on the Product-Oriented WBS by translating the components and subcomponents of the Key Deliverable into bundled work orders, which are further broken down into delegable work packages, focusing on optimizing work execution. While the A-WBS does not include time estimates, dependencies, or resource allocations, it is a crucial preparatory step for developing the project schedule, where these additional details will be incorporated. This way, the A-WBS bridges the static view of the PO-WBS with the dynamic timeline of the project schedule.
   • Definition and Planning of the First Two Work Packages from the Action-Oriented Work Breakdown Structure (WBS):
     A work package is the smallest unit within a Work Breakdown Structure (WBS) assigned to a team for execution. It describes a clearly defined set of activities required to complete a component of a larger deliverable. A work package includes: project name, component name and ID, work package name and ID, work package leader and team members, the product to be created, work description, assumptions, constraints, milestones, scheduled activities and resource planning, including cost estimation (personnel and material costs), and acceptance criteria (completeness, correctness).
7. Schedule Including Contingency Reserves and a Management Reserve: A detailed schedule that depicts the timeline of the most important milestones and contains the same elements as the action-oriented WBS. The schedule shows the scheduled milestones and includes risk allowances, ideally at the phase level, but at least at the overall project level. Additionally, it contains a management reserve available to the sponsor at the project level.
8. Budget Including Contingency Reserves and a Management Reserve: A cost plan that outlines the project costs based on the elements of the product-oriented and action-oriented WBS. It includes cost estimates per deliverable and per phase and contains risk allowances, ideally at the level of deliverables and phases, or at least at the overall project level. Additionally, it includes a management reserve available to the sponsor at the project level.
9. Analyzed and Prioritized Risks and the Respective Answers to Them: A table listing risks, prioritized in descending order of their respective criticality score, which results from the multiplication of their likelihood score and their impact score (sum of the impact scores on time, on costs, and on quality). For risks above a defined level of tolerance in terms of criticality score, there is a strategy type and a specific answer and risk owner defined.
10. Communications and Stakeholder Engagement Management Plan: A table showing methods for effective communication and engagement with project stakeholders, based on the analysis of their importance combined with their actual engagement, ensuring their needs and expectations are met. Includes a communication matrix showing who communicates to whom, how, and when.
11. Updated Project Organigram: A visual or textual description of the updated hierarchical structure of the project, showing levels such as project governance entity, project management entity, and work package execution entities, including their respective levels of authority.
12. Annexes: Include any relevant details from the previous sections. Provide the subsidiary management plans that explain how the following elements, for both predictive and agile components, are managed throughout the project: requirements, scope, schedule, cost, quality, communications, stakeholder engagement, human and material resources, risk, procurements, as well as issues and changes affecting the project baseline.