Our company

This project work is different from most project courses that you might have passed previously in your education. Here, we will simulate a "real" scenario, where you are employed in a simulated software development company.

All students in the course will be divided into separate companies, each consisting of approximately 25-30 students. This means multiple companies working independently and in parallel. During the semester, these companies are all producing a product and are talking to their respective customers. Hence, the companies are competitors, but also with some common interests.

Roles and Responsibilities

Within these companies, you will need to organize yourselves. You are given a high degree of freedom in this, but with some guardrails:

• There are responsibilities that you must cover in your organization
• You may map these to roles as you see fit
• You are provided a set of recommended starting roles to get you up and running, but may deviate from these roles as your project evolves

A responsibility is something that needs to be done by someone. A role can be thought of as a bucket of one or more responsibilities. Note that being responsible for something does not mean doing all the work. Delegation is key. To exemplify, the project manager — while responsible for project deliverables — is not expected to make those deliverables themselves.

Departments

There are many ways to organize a company. In this course, reflecting a common pattern in industry, your project organization is split into two departments:

• Product and Sales (P&S)
• Research and Development (R&D)

Required Responsibilities

The following responsibilities must be covered within your project organization. When you document your organization and your processes, you must be explicit in how you cover them.

Project Management

Ultimate responsibility for project deliveries: planning project activities, delegating tasks, following up, reporting road map and status to stakeholders. Leading and directing what the project does.

P&S Line Management

Responsibility for the members of the P&S department: their well-being, their workload, their competence. Supply the project with the talent it needs for success.

R&D Line Management

Responsibility for the members of the R&D department: their well-being, their workload, their competence. Supply the project with the talent it needs for success.

Product Management

Responsibility for final decisions on product design and strategy.

Analysis Lead

Responsibility for leading the analysis work: understanding, interpreting and communicating customer needs, understanding how to realize them as a product/service.

Quality Assurance Lead

Responsibility for assuring the quality of any and all deliverables, including testing, inspection etc.

Configuration Management

Responsibility for ensuring effective and efficient version control and configuration of all project artifacts, including code, tests, environments and documents.

Architecture

Responsibility for technical design decisions in the product: how to structure the product, which technology stack to use, which protocols and interfaces to use etc.

Process Management

Responsibility for ensuring effective and efficient processes for all activities throughout the project.

Technical Writing

Responsibility for writing documentation and documents.

User Experience Design

Responsibility for ensuring the usability of the solution.

Pipeline and Deployment

Responsibility for setting up and maintaining the continuous delivery and deployment pipelines, maintaining test harnesses, dashboards, deployment scripts etc.

Testing

Responsibility for performing manual tests and/or creating and maintaining automated tests.

Development

Responsibility for implementing the software to realize the product according to specifications.

Analysis

Responsibility for analyzing, understanding, interpreting and communicating customer needs.

Recommended Starting Roles

To get started, the following starting roles are recommended, per department. You may then experiment with splitting, merging and combining these roles as the project evolves.

P&S Department

• 1 Project Manager (Responsibility: Project Management)
• 1 P&S Line Manager (Responsibility: P&S Line Management)
• 1 Product Manager (Responsibility: Product Management)
• 1 Lead Analyst (Responsibility: Analysis Lead)
• 1 QA Lead (Responsibility: Quality Assurance Lead)
• 1 Technical Writer (Responsibility: Technical Writing)
• Multiple Analysts (Responsibility: Analysis)
• Multiple Testers (Responsibility: Testing)

R&D Department

• 1 R&D Line Manager (Responsibility: R&D Line Management)
• 1 Architect (Responsibility: Architecture)
• 1 Configuration Manager (Responsibility: Configuration Management)
• 1 Process Manager (Responsibility: Process Management)
• 1 Deployment Manager (Responsibility: Pipeline and Deployment)
• 1 or more UX Designers (Responsibility: User Experience Design)
• Multiple Developers (Responsibility: Development)

Teams

The project groups in this course are large enough that they need to be structured into smaller units: teams. An actual team (as opposed to a general collection of people) needs to be sufficiently small to function, with a typical size being 5-8 people. All project groups are required to organize into teams, and it is these teams that take responsibility for and execute the work in the project.

The precise method you choose for structuring your teams is up to you, but be aware that there are alternatives, and we want you be explicate your line of reasoning and motivations: why do you choose the structure you choose, what do you hope to gain by it, what challenges do you perceive and how do you plan to deal with them?

Note that all project members, regardless of role, shall be part of and contribute to the work of a team. This includes managerial roles.

An organization where teams are formed within within separate functional departments (e.g. in R&D and P&S separately) tends to become very rigid and slow when development ramps up. Hence, cross-functional teams are strongly recommended (and required for higher grades, see Project grade). Such teams include members from each department, with the ambition of being "whole" in the sense that they can take end-to-end ownership of a customer need all the way to realized customer value. This ambition may be difficult to achieve in practice, but is important to strive for.

There are multiple strategies for forming such teams, and none of them is perfect: responsibilities need to be divided somehow, and no matter how you choose to do it you will run into issues. That's part of the learning experience.

A common approach to forming cross-functional teams is to center them on some well-defined part of the architecture, letting them take responsibility for any work impacting that part of the product. This is straight-forward, but comes with certain downsides (e.g. coordination and integration challenges, and likely workload imbalance). Another approach is to expect the teams to be able to operate across the entire product and handle any customer need. This is in some ways more demanding of the teams, but not unreasonable given the limited scope of the project.

Note that when working in a cross-functional team one collaborates closely with colleagues in different roles. To exemplify, an analyst might work closely together with a developer and a tester to jointly realize some customer value (rather than working in separate teams and handing work items off to one another). That doesn't mean that they don't need to coordinate with colleagues in the same role. In other words, while the analyst in the example works with other roles to create value, they are simultaneously in touch with other analysts, working in other teams, to share information, discuss options and ensure the consistency of the overall solution. A useful way of thinking about this is as a two-dimensional organization, sometimes referred to as a matrix organization.

Page responsible: Martin Sjölund
Last updated: 2026-05-25