Software Project Management (SPM)

Why is SPM important?

1. Software's Big Role:
   Software controls more and more of what we do every day. It's everywhere, from our phones to our power grids.
   

2. Big Money: Countries spend a lot of money on software. It's a big part of their economies.
   

3. Historical Problems: There have been problems with making software for a long time. Even though we've come a long way since the 1960s, building software is still hard.
   

4. Growing Complexity: Software keeps getting more complicated. This makes it harderto build without good management.
   

5. Continuous Learning: We're always trying to get better at building software. That's why we need good software project management—to keep improving and making sure things work well.

History of SPM (the idea of SPM) - Events:

1968, conference "The Software Crisis"
People concerned that managing Software Projects had to be more systematic (Birth of S.E)

70s-80s:
Techniques for managing software systems were proposed & utilized. And different standards suggested, adopted & utilized.

And even after 50 years, the problem still persists.

But problems still arise to this very day & cost a signifanct amount of money.
Idea of SPM - so important that its embeded in everydays culture.

Why is SPM important?

1. Software's Big Role:
   Software controls more and more of what we do every day. It's everywhere, from our phones to our power grids.
   

2. Big Money: Countries spend a lot of money on software. It's a big part of their economies.
   

3. Historical Problems: There have been problems with making software for a long time. Even though we've come a long way since the 1960s, building software is still hard.
   

4. Growing Complexity: Software keeps getting more complicated. This makes it harderto build without good management.
   

5. Continuous Learning: We're always trying to get better at building software. That's why we need good software project management—to keep improving and making sure things work well.

History of SPM (the idea of SPM) - Events:

1968, conference "The Software Crisis"
People concerned that managing Software Projects had to be more systematic (Birth of S.E)

70s-80s:
Techniques for managing software systems were proposed & utilized. And different standards suggested, adopted & utilized.

And even after 50 years, the problem still persists.

But problems still arise to this very day & cost a signifanct amount of money.
Idea of SPM - so important that its embeded in everydays culture.

What is a Project?

A planned piece of work, designed to:

• Find information about something

• Produce something

• Or to improve something

Book (Diagram):

• Left (Jobs/Routines)

  • Not Projects - engraved in our way of working that dont reach complexity that the project has.

    • i.g. Prepare coffee, Brush teeth. (maybe first time - planned, but over the years become routine)

• Right (Exploration)

  • Uncertainty of the outcome, dont know if we can achieve something.

But in reality:
Instead of focusing on the boundaries, focus on the characteristics of the project instead. This way you can build an idea of what the project will be like.

Characteristics of a Project

• Non-routine tasks are involved.

• Planning is required.

• Specific objectives are to be met or a specific product is to be created.

• The project has a predetermined time span.

• Work is carried out for someone Other than yourself.

• Work involves several specialisms.

• People are formed into a temporary work group to carry out the task.

• Work is carried out in several phases.

• The resources that are available for use on the project are constrained.

• The project is large and complex.

  
  
  Not all of them need to be there, but some of them do:

• 5. Client and a vendor relationship

• 7. Many different facets depending on the organisational structure & how human ressources are managed within the company & organisation

A different POV for a Project:

A project (path) that brings us from

• A Current State

• To a Desired State

 

Project Manager - in charge of:

• Steer the project in the direction based on whatever insight (which line) is more optimal.

Project Lifecycle

Overlaps the development life cycle: (Requirement Analysis, System Design, Implementation, Testing, Deployment, Maintenance)

The Project Lifecycle:

• Initiation

• Planning (Which Software Development Process to utilize)

• Executing (Perfoming Software Development), Monitoring, Controlling

• Closing

SPM vs. PM - What is special?

There is no silver bullet that would work for any kind of project.
Every single product/SP will be different in several ways. We cannot like for instance in civil engieering rely on physics. Complexity cant be predicted.

Brooks talks about 4 characterstics:

• Complexity

  • Many parts are involved, making development difficult

• Conformity

  • Software closely aligning with user needs & specifications and other systems it interacts with.

• Changeability [Flexibility]

  • Software needs to adapt to changes in requirements and technology, but it's hard to make it flexible.

• Invisibility

  • Unlike physical objects, software is intangible, making it hard to understand and work with.

What is a Method/Process Model?

Abstract representation of a systematic way of accomplishing something.
(i.e. Scrum, Waterfall)

What is a Methodology?

A series of related methods guided by some principles (e.g. Agile methods)

What is a Plan?

Implementation of a Method.

What is a Practice?

 The observable implementation of a plan.

What is a Product?

 A group of software systems with similar features, tailored to meet the needs of a market segment/mission.

Conway's Law

When the structure of the system mirrors the structure of the organization that designed it. This relation, Conway argued, is a necessary consequence of the communication needs of the people doing the work. The point of structure is to support coordination of the development work.

Organizational structures and projects

On a large project, there could be several groups contributing to different aspects of the project. Some organizational structure is needed to form and manage these groups. Based on the organizational structure we achieve a specific behavior among your human resources.

Formal structures

The formal structure focuses on authority, about who has which boss.

Informal structures

An informal structure of contacts and communication emerges spontaneously between members of staff while working. This system takes over when the unexpected happens.

Hierarchical approach in organizational structures

The 'traditional' management structure is based on the concept of the hierarchy - each member of staff has only one manager, while a manager will have responsibility for several members of staff. Authority flows from the top down through the structure.

Staff versus line in organizational structures

Staff in organizations can often be divided into line workers who actually produce the end product and support staff who carry out supporting roles.

Departmentalization in organizational structures

Software development is usually organized using either a functional or a task-oriented approach. With functional departmentalization, systems analysts may be put in a separate group from the programmers. The programmers would act as a pool from which resources are drawn for particular tasks. With a task-oriented approach, the programmers and systems analysts are grouped together in project teams. However, having separate departments could lead to communication problems, especially if a developer is unfamiliar with an application area.

Most famous organizational structures

Divisional
Egoless
Hierarchical
Line
Line and Staff
Matrix
Project
Staff or Functional Authority

Line organizational structure

The line structure is the simplest one. A very clear chain of command - taking a decision is direct and there is no questioning. If i say jump the person jumps. Very efficient when you need to make quick decisions - works well in the military but not so well in other settings.

Matrix organizational structure

In a matrix structure, individuals work across teams and projects as well as within their own department or function. For example, a project or task team established to develop a new product might include engineers and design specialists as well as those with marketing, financial, personnel and production skills.

Egoless programming in organizational structures

Egoless programming solves a bunch of problems regarding code ownership and ensures more readable code through an iterative feedback loop. In contrast to hierarchical structure, it encourages collaboration above all else. Several of the principles of extreme programming share principles from the egoless programming structure. Agile processes have traces of it.

Hiearchical organizational structure

Has a decided leader at the top of the pyramid where decisions can be made efficiently.
There is always one above you. Every member can focus on their specific job without letting bigger decisions stop their workflow.
This also means that the work can be delegated, so the top layer does not have to micromanage the lower employees. It is the complete opposite of egoless programming.

Divisional organizational structure

The divisional structure groups each organizational function into a division. Each division contains all the necessary resources and functions within it.

Line and staff organizational structure

Composed of one group of employees who achieve the goals of the organization (the line), and another group who support the line (staff).
Line and staff is the organization structure, in which there is a normal departmentation of the regular business operations, and there is the functional specialist to perform specialised activities. While line authority relies on command, line and staff authority is based on command and advise.

Staff or Functional Authority organizational structure

The company is split up into different sections like marketing and quality assurance and financial departments. Those departments all have their individual experts. The traditional line structure is still present, but the different roles can help across the branches so they can supervise the other parts of the company.
Some of the problems are that a person in the company might have multiple bosses that see the different tasks from different angles. This can make it difficult for the person to know which instructions to follow.

Project organizational structure

It is a temporary organization that uses teams of specialists. The project team focuses every resource they have on the assigned task. Once the project has been completed the team members can go back to their original tasks, or maybe they are assigned to a new project. This structure is used when the work is defined by a specific goal.
It can be a tough domain to work in because it is common that the company hires human resources when a project arises, and then most of those people are let go after the project is finished.

General roles in a project

Client

Contractor

And on the contractor’s side:
- Requirements Engineers
- Architects
- Developers
- Testers and Integrators
- Product Owner
- Scrum Master

What is a Client?

Responsible for basic decisions and requirements

Controlling and acceptance

Participation in QA

Has the money

What is a Contractor?

• Responsible for conducting the project

  • Organizes tasks, sets timelines, assigns responsibilities, and ensures everyone stays on track towards the project's goals.

• Performs the development

  • They actively engage in creating or executing the project, whether it involves coding, designing, writing, or any other necessary tasks to bring the project to fruition.

• Wants the money

The project manager role

Responsible for achieving project- and contract goals within the set parameters.

Steers the team, keeping them motivated, to achieve project and contract goals within budget, time, and quality constraints.

- Define the project “volume” (scale/size of project - work, ressource, scope)
- Organize and motivate the team
- Create "small successes” (achievements - milestones, i.g. finishing a specific task of the project on time and within budget, hitting key deliverables, positive feedback) on the road
- Balance the "Devil's Square" (Cost, Time,
Quality, Functionality)
- Manage sub-contractors and vendors
- Organize delivery and acceptance

Other important Roles

• Quality Manager:

  - Makes sure everyone follows quality rules and standards.

  - Uses tools to check and make things better.

• Project/Company Steering Boards:

  - Groups with project and quality managers, stakeholders, etc.

  - They check things and make big decisions. Project managers tell them what's happening.

• Other Boards:

  - Groups for planning and talking.

  - Groups for steering projects, products, and changes.

  - Groups for improving quality and processes.

• C-level Officers:

  - Top bosses like CFO, CTO, CEO, etc. They make big decisions for the whole company.

Problems with Roles

Switching roles in a software team can be tough. Imagine someone loves their job, but suddenly they have to do something completely different. That can be really hard for them to accept. So, it's crucial to manage role changes sensitively to ensure everyone feels comfortable with their new responsibilities.

Roles can be a minefield! Here's why:

- Terminology: Different roles have different names, which can be confusing.

- Software Specificity: Roles are tailored to the software process, making them hard to apply elsewhere.

- Assignments: Figuring out who does what can be tricky.

- Responsibilities vs. Power: Sometimes, roles don't match the authority they need.

- Company Structure: Roles should fit the company's hierarchy.

- This is a big headache, especially when creating software processes just for one company!

What is a Business Case (Feasibility Study)

Cost-benefit analysis helps decide if a project is worth it by comparing costs to future benefits. It's usually done at the start of a project (Portfolio level of a company, business cases are submitted) to see if it's feasible depending on whatever criteria they make. The sooner the project finishes, the sooner you get the benefits, which is better. The project plan must ensure business case is kept intact (e.g. cost of project don't go over the value of the benefits)

What is a Business Model

A plan that details how a company creates, delivers, and generates revenues

Business Case Objective

To give the rationale for the project (it will exceed development costs, benefits of the project, etc).

Business Case Document

1) Introduction and background to the proposal:
Describes the current environment. Describes the problem or opportunities that the project aims to address.

2) The proposed project:
A brief outline of the project (What does it aim to achieve)

3) The market:
Only included when a project is a new product.
Describes demand, likely competitors for new products.

4) Organizational and operational Infrastructure:
Describes how the organizational infrastructure will change. More relevant if a project modifies the information system or if a new distribution system has to be set up for a new product.

5) The benefits:
Describe the financial value of the project. If the organization is non-profit, other benefits can be mentioned.

6) Outline implementation plan:
fx which project activities can be outsourced, which should be in-house. Describes the management of the implementation; responsibilities are allocated, key points or milestones are identified. For large implementation, it may need to be divided into several projects and managed as a programme.

7) Costs:
A schedule of expected costs associated with the project.
Helps to ensure financial ressources are managed effictively throughout its execution.

8) The financial case:
Analysis of income and cost over project lifespan.
Clear understanding of financial implications & potential return on investment.

9) Risks
Potential problems (risks or obstacles) impacting project success and solutions to mitigate these risks in ensuring successful project delivery.

10) Management Plan
How the project will be handled.