This project work will probably be a bit different from other 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. In a typical year, this means 4 companies working independently and in parallel. During the semester, these companies are all producing a product and are talking to their respective customers, this year Region Östergötland. Hence, the companies are competitors, but also with some common interests.
Below you will find requirements and recommendations for company organization and internal structure. These apply to all companies equally. The requirements shall be followed, unless there is a very good reason to deviate, meaning there are external factors (e.g. a particular business context or customer requirement that causes a conflict). If you decide to deviate from these recommendations, make sure to bring it up with course personnel and secure their approval. The recommendations, on the other hand, you can take or leave. Just know that they are based on many years of experience, so treat with caution. Roles can also be added if there are good reasons for that.
OrganizationThe company consists of two different departments:
- The Product and Sales (P&S) department.
- The Research and Development (R&D) department.
Product & Sales (P&S) Department
The P&S Department is responsible for having continuous contact with the customer and cooperation partnesr. They are creating and negotiating requirements with the customer and cooperation partners and are performing acceptance testing.
The P&S Department is also responsible for high-level testing (e.g. system, usability and acceptance testing) of the product and maintaining and updating the operational environment.
Examples of roles within the P&S department:
- Required:P&S Manager (the line manager for the department)
- Required:Project Manager
- Recommended:Lead Analyst
- Recommended:Product Manager
- Recommended:Test Leader
- Recommended:Quality Coordinator
Research and Development (R&D) Department
The R&D Department is responsible for design, implementation and, and low-level testing (e.g. unit and integration testing) of the system. Input for the design comes from the P&S department and tested versions of the system are delivered to the P&S department for high-level testing, acceptance and delivery.
Apart from developing the product itself, the R&D Department is also responsible for creating and maintaining the infrastructure required for successful development and delivery, such as test frameworks and continuous delivery and deployment pipelines.
Examples of roles within in the R&D Department:
- Required:R&D Manager (the line manager for the department)
- Recommended:Lead Architect
- Recommended:Configuration Manager
- Recommended:Process Manager
- Recommended:Technical Writer(s)
- Recommended:Deployment Manager
- Recommended:UX designer
Working with a role
The roles are selected early in the course on a limited set of information. The roles sometimes need further clarification or development to work smoothly in the company. It might very well happen that you want to change roles. This is fully OK as long as you inform supervisors and the examiner. Many roles are part-time and in practice all people need to help with coding or testing. Going outside of your assigned role - going above and beyond to take a broader responsibility for the project - is appreciated, but not at the price of neglecting your primary responsibilities.
When selecting roles, note that non-technical skills may be deciding. In particular, some information from the customer might be in Swedish, which is worth considering when selecting roles.
Also note that formal responsibility for an area is not the same as doing all the work. Formal responsibilities are important - if they are unclear to you, you should take this as a warning sign! But that doesn't mean you can't be flexible in who does what, stepping in for each other and responding to challenges as they arise. Think of the formalism as your last line of defense - it needs to be there for you to fall back on, but as you grow into your roles it will be easier for you to improvise. This is what we mean by "Structured, but pragmatic" (see Project grade). While most of the roles above are recommended but not required, think of them as a useful indication of what the R&D Manager and the P&S Manager are responsible for and need to delegate.
Finally, it is important to understand the separation of responsibilities between the Project Manager and the P&S Manager. The Project Manager is responsible for planning the project and following up its execution: what gets done when, in which order, understanding the dependencies, identifying risks and obstacles etc. The P&S Manager (and similarly the R&D Manager) is responsible for their department, its operational excellence and the well-being of the its members. Think of the departments as tools at the Project Manager's disposal to get the job done, with the department managers as responsible for those tools being in the best possible shape.
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: Kristian Sandahl
Last updated: 2023-08-24