Skip to content

Commit

Permalink
refs #148: All info about project roles (#204)
Browse files Browse the repository at this point in the history
* refs #148: WIP on the project roles new section.
* refs #148: The bulk of the info is there. Needs a double-check.
* refs #148: Added missing links.
* refs #148: Refinement of new sections.
* refs #148: The new section should be over now.
  • Loading branch information
stickgrinder authored Oct 26, 2023
1 parent e5a6f53 commit 85b4cda
Show file tree
Hide file tree
Showing 9 changed files with 280 additions and 5 deletions.
27 changes: 27 additions & 0 deletions content/organization/accountabilities.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,3 +55,30 @@ As you gain [seniority](/organization/operations#seniority-levels) and possibly
### Digital Strategy area

`TO BE DONE`

## Project-roles accountabilities

Project-related accountabilities are described in terms of their ownership, practical tasks and expected observable outputs.

The accent is on practices because these roles are often taken up by developers, engineers, designers and in general by colleagues with a technical expertise. Also, this model does not conflict with the shared and seniority-related accountabilites listed above.

Different models are available based on the delivery area.

### Development area

* [Analyst](/resources/projectroles-acc-analyst)
* [Architect](/resources/projectroles-acc-architect)
* [Team Leader](/resources/projectroles-acc-team-leader)
* [Project Manager](/resources/projectroles-acc-project-manager)

Whomever works on a project without being explicitely appointed any such roles, has the [Team Member](/resources/projectroles-acc-team-member) accountabilities.

Learn [how these roles collaborate and interact](/organization/operations#interactions-between-development-project-roles).

### Platform area

`TO BE DONE`

### Digital Strategy area

`TO BE DONE`
Empty file.
2 changes: 1 addition & 1 deletion content/organization/governance.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ The executive board is in charge of the strategy and business planning of the co
The current board is composed of company founders, with the following duties.

* **Stefano Mainardi**: CEO - Responsible for the overall progress of the company. Praised for success, and held responsible for setbacks.
* **Paolo Pustorino**: Head of HR - Responsible for workforce training, development, management, recruitment, rewarding, compliance and ethos.
* **Marco Giacomassi**: CFO - Oversees the company's financials. Responsible for budgeting, accounting, reporting, forecasting and investing.
* **Paolo Mainardi**: CTO - Oversees the company's technology. Works to ensure that technology-related decisions align with business goals.
* **Alessio Piazza**: COO - Oversees the company's day-to-day operations, sourcing, process control, resource allocation and activity planning.
* **Paolo Pustorino**: Head of HR - Responsible for workforce training, development, management, recruitment, rewarding, compliance and ethos.
53 changes: 49 additions & 4 deletions content/organization/operations.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ Each of these branches contains one or more teams focused on specific projects o
SparkFabrik has an almost flat organization, arranged around clear roles, each with its ownership and responsibilities.
Also, people grow in seniority and this grants them more authority on specific issues or in specific situations.

Every [operational area](/organization/operations) has its seniority levels, while project roles are common to every area, even if some may not be relevant or applicable.
Every [operational area](/organization/operations) has its seniority levels and project roles.

### Seniority Levels

Expand All @@ -62,21 +62,66 @@ We recognize three levels of professional skills, each with its salary bracket,
* **Practitioner Cloud Engineer**: people at this level are skilled at and proficient with a bunch of different cloud technologies and have absorbed our methodology. They can mentor newcomers as well as developers and are autonomous in their work.
* **Architect Cloud Engineer**: experienced professionals with diverse exposure across various cloud platforms and technologies. They can take on complex projects independently, engaging with the client and coordinating the work of their colleagues.

Learn more about [each level's accountabilities](/organization/accountabilities) and how we evaluate people's seniority level.
Learn more about [each level's accountabilities](/organization/accountabilities#seniority-related-accountabilities) and how we evaluate people's seniority level.

#### Digital Strategy Area

`TO BE DONE`

### Project Roles

Depending on seniority, attitude, achievement, and personal inclinations, SparkFabrik may propose people take over one or more of the following roles on a project. Not all roles are accessible at all seniority levels and more junior employees should not expect to be assigned one.
Depending on seniority, attitude, achievements, and personal inclinations, SparkFabrik may propose people take over one or more of the following roles on a project. Not all roles are accessible at all seniority levels and more junior employees should not expect to be assigned one.
Being appointed a project role means **you earned the company's and teammates' trust**, you proved your **reliability** and you display a strong **customer orientation**.

These roles are not mutually exclusive, even if covering all at the same time is usually unfeasible, and not all projects need all of these roles to be clearly appointed.
These roles are not mutually exclusive - even if covering all at the same time is usually unfeasible - and not all projects need all of these roles to be clearly appointed.
To better understand the relation between seniority level and project roles in terms of professional growth, visit the section on [career advancement](/working-at-sparkfabrik/career-advancement).

#### Development area

In development projects, we recognize the following project roles.

* **Analyst**: Analysts are great when it comes to mapping a domain, fathoming complexity, and expressing it in a clear, rational, understandable form. Analysts may not always have a solution at hand but for sure they know when a need is fulfilled or a problem is solved. If need be, analysts' skills make for great product owners.
* **Architect**: Architects describe the best possible solution to a framed problem. They are great decision-makers, understand the long-term implications of technical choices, know how to quickly probe, understand and adapt and always grasp the big picture.
* **Team Leader**: Team Leaders excel at enabling teams, coordinating efforts, and ensuring project milestones are met. Focused on the outcomes, they drive, motivate, and keep the team committed to the project's success. They ask hard questions, suggests alternative paths, and apply a good deal of common sense to risk management.
* **Project Manager**: Project Managers make things work. They coach, measure, look ahead, warn, and ultimately support people to give their best, removing obstacles, and improving their processes and procedures. In SparkFabrik people are never managed - work is. So Project Managers govern but never rule.

Learn more about [each role's accountabilities](/organization/accountabilities#project-roles-accountabilities) and how we evaluate their outcome.

#### Interactions between development project roles

To prevent overlap in problem-solving and avoid the bystander syndrome (stuff that can wreck projects and interpersonal relationships alike) we've provided a RACI <sup><a href="#fn1">1</a></sup> table below that clarifies roles and responsibilities throughout the project's various phases.

In applying this clear information to your daily work, always keep in mind that effective teamwork and communication are essential for the success of our initiatives.


| Activity / Role | Team Leader | PM | Solution Architect | Analyst | CTO | COO |
|-----------------------------------------------------|:-----------:|:--:|:------------------:|:-------:|:---:|:---:|
| Pre-sales estimates | C | A | R | R | C | I |
| Initial analysis | C | I | C | AR | I | |
| Epic/Milestone Mapping and Project plan | R | A | C | R | | C |
| Functional requirements and backlog population | R | C | C | A | | |
| Definition of the work team | I | R | C | I | C | A |
| Week/sprint planning | A | C | R | C | | |
| Coordination of team activities | A | C | R | C | | |
| Drafting technical documentation | A | | R | C | I | |
| Retrospectives and corrective actions | A | C | R | R | I | I |
| Iteration events (plan, review, etc) | A | C | R | R | | |
| Customer communications | R | A | C | R | I | I |
| Monitoring and evaluating progress | R | A | C | C | | I |
| Coordination of external dependencies (other teams) | C | R | I | I | C | A |
| Definition of the solution | C | I | AR | C | C | |
| Compliance with best practices | R | | A | | C | |
| Smoke-Testing e QA | R | I | R | A | | |
| Technical rebuilding | I | R | A | | | |

#### Platform area

`TO BE DONE`

#### Digital Strategy area

`TO BE DONE`

---

<small><a name="fn1">1</a>: For sake of clarity, read the table as follows: **Responsible**: who's practically performing the task or decision. **Accountable**: the _single_ person held responsible for the outcome (you can call them "owner"). **Consulted**: People that MUST be consulted for information or validation before completing the task or decision. **Informed**: People that must be kept in the loop about that task or decision.</small>
45 changes: 45 additions & 0 deletions content/resources/projectroles-acc-analyst.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
/*
Title: Ownership - Analyst
Description: Ownerships of an Analyst on SparkFabrik's projects
Sort: 200
*/

Analysts are great when it comes to mapping a domain, fathoming complexity and expressing it in a clear, rational, understandable form. Analysts may not always have a solution at hand but for sure they know when a need is fulfilled or a problem is solved. Analysts' skills make for great Product Owners.

Analysts are responsible for the functional analysis of products and services on behalf of the customers. They define the requirements for its features and contribute to populate the work backlog. They are tasked with maintaining consistency between product's functionalities and ensuring that the requirements are clear and well-described, ready to be worked on by the team.

They do not handle the technical direction of the project (thus, they do not evaluate individual implementations from a technical perspective) nor the management of deadlines, budgets, and external priorities unrelated to the product.

## Caveats

The analyst must maintain continuous involvement with the client and the project, much like the [Project Manager](/resources/projectroles-acc-project-manager). They are not usually assigned on-call as they are the owner of client request analysis and need continuity and full visibility to perform effectively.

They must comprehensively analyze and manage client requests throughout the project's lifespan. This requires a sufficient technical background to put forward proposals, without necessarily making technical decisions themselves, taking into account the impacts those have on the implementation.

## Ownership

* Analysis and definition of functional requirements
* Preliminary analysis during the pre-sale phase
* Quality assurance and smoke testing

## Practical tasks

* Contributes to pre-sale estimates
* Performs initial analysis and development of the functional technical document (with the [Project Manager](/resources/projectroles-acc-project-manager) and [Solution Architect](/resources/projectroles-acc-architect))
* Collaborates with the [Project Manager](/resources/projectroles-acc-project-manager) in drafting the project plan (roadmap)
* Leads functional requirements validation
* Defines the requirements (with the Client)
* Drafts the issues in terms of functionality description, acceptance criteria, and validation scenarios
* Maintains requirements documentation

## Tangible outputs

* Documents with pre-sale estimates
* Functional analysis documents (conceptual map, structure, etc.)
* Project backlog and requirement documentation
* Acceptance test cases

## Interactions

Please, visit the [Interactions between project roles](/organization/operations#interactions-between-development-project-roles) section.

45 changes: 45 additions & 0 deletions content/resources/projectroles-acc-architect.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
/*
Title: Ownership - Architect
Description: Ownerships of an Architect on SparkFabrik's projects
Sort: 210
*/

Architects describe the best possible solution to a framed problem. They are great decision makers, understand the long-term implications of technical choices, know how to swiftly probe, understand and adapt and always grasp the big picture.

The Solution Architect serves as the technical leader for a product. They are responsible for defining the solution's architecture, its dependencies, and the services it encompasses. They actively participate in development alongside the rest of the team, encouraging each member to proactively address problems based on their seniority.

The Solution Architect defines strategies to ensure the quality of product implementation, starting with adherence to best practices already established within the company. They seek validation from the CTO if they believe it is necessary to evolve or introduce new practices. They participate in internal calls and those with the client when specialized technical input is necessary or preferred.

## Caveats

Large projects may need specialized software architects for different areas (say, frontend and backend). Nonetheless, a single Solution Architect should be designated for each project to ensure coordinated choices, adherence to [Universal Definition of Done](/tools-and-policies/universal-dod), and alignment with non-functional requirements.

Small projects with limited technical complexity may not require a dedicated Solution Architect. In such cases, responsibilities can be delegated within the team, under the Team Leader's guidance.

## Ownership

* Technical architecture of the product
* Technical documentation of the product
* Technical quality of implementations and adherence to best practices
* Alignment of the technical solution with functional requirements
* Promotion of technical innovation within the team

## Practical tasks

* Coordinates and conducts pre-sale estimates
* Defines non-functional requirements (performance, security, operational costs, solution scalability, etc.)
* Defines the technical project architecture
* Drafts technical architecture documents and ADRs (Architecture Decision Records)
* Provides internal technical advisory
* Conducts (delegating at their discretion) technical reviews of work (code-reviews, etc)
* Ensures the establishment of DevOps practices

## Tangible outputs

* Technical documentation for project architecture and ADRs (Architecture Decision Records)
* Initial solution stub with the team
* Technical implementation

## Interactions

Please, visit the [Interactions between project roles](/organization/operations#interactions-between-development-project-roles) section.
42 changes: 42 additions & 0 deletions content/resources/projectroles-acc-project-manager.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
/*
Title: Ownership - Project Manager
Description: Ownerships of a Project Manager on SparkFabrik's projects
Sort: 230
*/

Managers make things work. They coach, measure, plan ahead, warn and ultimately support people to give their best, removing obstacles, and improving their processes and procedures. In SparkFabrik people are never managed -- work is. So managers govern but never rule.

The Project Manager maintains an overview of the project's progress, ensuring that the roadmap is understood, followed, and evolved in collaboration with the Client - when new information arises during the project's execution.

They interact with the team as coaches and facilitators, by feat of their high-level perspective, working to eliminate impediments that could slow down productive processes or grind them to a halt. During crises, if required by the board or the team, they may need to enforce corrective actions, assuming control of the project and adopting an assertive stance until ideal working conditions are restored.

Project Managers are responsible for progress, budgets, and other key indicators, report any program deviations to the board and the client, and maintain an analytical eye on processes to suggest corrective actions and improvements. In particular, they monitor the team to address any discrepancies from contractual obligations, whether they are shortfalls or overages, and bring this to their attention, so the team can reorganize around this information.

## Ownership

* Budget
* Timeline and deadlines
* Processes
* Contracts
* Roadmap / Milestones definition and maintenance

## Practical tasks

* Collaborates in the team's weekly planning (with [Analysts](/resources/projectroles-acc-analyst) and [Solution Architects](/resources/projectroles-acc-architect))
* Meetings agendas
* Project priorities negotiation
* Activity reporting (during retrospectives with [Analysts](/resources/projectroles-acc-analyst) and [Solution Architects](/resources/projectroles-acc-architect))
* Contractual project overseeing
* Facilitation of dialogue with Management and Client
* Keeping project documentation
* Billing management in coordination with the administration

## Concrete outputs

* Monthly reporting (internally and externally)
* Service Level Agreement (SLA) documentation
* Formalization of substantial deliveries

## Interactions

Please, visit the [Interactions between project roles](/organization/operations#interactions-between-project-roles) section.
Loading

0 comments on commit 85b4cda

Please sign in to comment.