Business Unit Management Guidelines

Resource Management

There are several objectives related to resource management:

• Optimizing the BU capacity across all projects.
  • Minimizing unassigned members
  • Maximize members productivity
    We care about people and we should avoid people working in 10 projects at the same time to fullfill the whole possible capacity.
• Monitoring business performances of the Business Unit.
  • Efficiency
  • Gross Margin

Demand & Capacity Planning

• Every BU maintains a specific capacity plan

Project Portfolio Management

There are some activities related to resource management:

• Selling a project
• Starting a project
• Closing a project
• Optimize project allocation
• Customer caring and planning

Project Portfolio Management Concepts

• A project requires a team assigned to it. Each project has a corresponding Account in the circle Sales.
• Members assigned to a project determine the project allocation.
• A project may require a number of resources greater than the team members assigned to a project.
• The requested number of people determines the project demand.
• A project may require different roles, each role can be associated to a specific rate.
• The association of roles to rates is up to the Account.

Selling a project

A new project requires alignment between Sales, Engine and the BU to get the best fit for the following constraints:

• Roles and rates
• Available capacity

This may require:

• Hiring new members in time to start
• Reducing members allocated to other projects and assign them to the new one
• Dropping the project if there is not a good fit

Start a project

After selling projects, a BU Lead Link must setup the project:

• Knowledge transfer between the pre-sales team and the project team
• Definition and understanding of customer expectations
• Acquisition of customer methodologies or procedures
• Team building

For these reasons, a proper and extensive communication is important.

Here some checklist to help to drive this phase

Checklist for the BU Lead

• Define the team and communicate to members about the start of the project with the relative timeline.
• Define who is the Project Leader and communicate this to him/her.
• Assign an Architect to the project and provide him a link with the pre-sales architect for their alignment.
• Create a group/channel/folder on office365 and set the Project Leader as the owner of the group.
• Check the project on elapseit, budget, costs, and team.
• Give the Project Leader admin access to the project on elapseit.
• Load on project SharePoint all pre-sales materials.
• Notify the Engineering Office about the new project.
• Organize an internal kick-off with the team with the following goals:
  • Provide the proper context about the customer, the project, high-level strategy.
  • Involve the customer Account and Sales ( if needed ) to explain the customer strategy.
  • Define and explain team roles.
  • Involve the CTO or the PreSales Architect to explain the technological landscape.
  • Define what are the customer needs, expectations and priorities.
• Debrief with the team leader to be sure everything is clear and alignment is complete.
• Organize the kick-off with the customer with the following goals:
  • Introduce the team and create a link with the team leader.
  • Clarify to the customer the team set-up with relative roles and accountabilities.
  • Be sure that the next step will be defined.
• Support the team leader for the first two weeks to smooth communication and operations, providing context and strategy.

Checklist for Project Leader

• Check that BU Lead covered all the steps.
• Define and share the development process, trying to fit our best practices with the customer's ones.
• Ask for git repositories to GitLab Administrator.
• Ask for cloud infrastructure to Internal IT (if needed) .
• Be sure that architectural and technological landscapes are clear, otherwise ask for deep dive with the architect.
• Check the frameworks and languages guidelines to define the software development tech stack ( Sharepoint: Bigdata --> Engineering )
• Verify that all members understood goals, priorities and the solution.
• Define and share a first draft of the backlog to be sure that all members are aligned.
• Establish a good level of communication with all the team members ( including 1-1 meetings ).
• Establish a good level of communication with the customer.
• Periodically (since the beginning) verify that customer needs, expectations and priorities are still the same explained by the BU Lead or Account.
• Don't wait for the customer, be proactive.
• Start communicating with the Business Unit Architect(s) to align with the company practices

Checklist for Architect

• Deeply align with pre-sales Architect.
• Be sure to have a clear context about the technological landscape of the customer, what is allowed and sustainable and what is not.
• Check the frameworks and languages guidelines to define the software development tech stack ( Sharepoint: Bigdata --> Engineering )
• Draft a first HLD to better transfer knowledge to the team.
• Establish a good level of communication with the team and with the customer ( don't act behind the team leader ).
• Follow closely the team for the first weeks, to avoid pitfalls.
• Understand immediately if there are technical shortcomings to address.
• Start communicating with the Business Unit Architect(s) to align with the company practices

Checklist for Team Member

• Help team leader as much as you can, in particular in the start-up phase.
• Be sure that architectural and technological landscapes are clear, otherwise ask for deep dive with the architect.
• If strategy, goals or other is not clear, don't hesitate to ask, alignment on purpose is making the difference.
• Establish a good level of communication with the team and with the customer. We don't want a ghost team behind the team leader, let's show our synergy and organization.
• Be proactive.
• Start communicating with the Business Unit Architect(s) to align with the company practices

Closing a project

Closing a project requires multiple actions:

• Relocation of team members to other projects. Planning in advance would reduce the unassigned capacity of the Business Unit.
• Collecting materials and make documentation available and reusable for the company.
  • Estimation and planning: useful for future estimations
  • Architecture and ADRs
  • Key developments

Optimize project allocation

Sometime it is clever to move team members around projects to find a better balance between skills, productivity and serenity while keeping always in mind also customers' needs. People fragmented over multiple projects would reduce productivity and allegedly increase stress. Another example may be the case of members allocated on repetitive activities. This may result stressful with the risk to lose productivity and engagement by the members of the BU. Nevertheless, everyone must be proactive and productive making their best for Agile Lab to be succesful. Repetitive tasks can be automated, bad practices and be improved, technical debt can be reduced. We love agilers making their project a better place to work.

Relocation

There are some risks tied to relocating people to different projects

• Time for onboarding
• Knowledge transfer
• Customer satisfaction

This is the reason why we must reduce onboarding time optimizing documentation and adopt bou scout rules. Customer satisfaction in important as well and we must strive to make customer confident with our moves.

Project Management

Team Preparation

Team preparation depends on actual planning. This is a delicate phase that is difficult to predict exactly. The goal of the BU Lead is to minimize downtime and limit the risks due to premature team allocation. Indeed, it often happens that clients stall for an unspecified period in order to organize themselves internally. In this context, the formation of the team should consider the involvement of the Engineering Director and HR in order to coordinate the procurement of resources.

The team composition is as follows:

• Project Leader - mandatory
• Developer - mandatory
• Architect - mandatory
• DevOps - optional
• PMO - optional
• Account - optional

Kick Off planning

The Kick Off is normally organized by Account and BU Lead, making sure that an initial meeting is convened to discuss timing and modalities.

Kick off meeting

A project starts with a kick off meeting. The purpose of the kick off meeting is discovering reference people and coordination points.

Project initiation

The kick off meeting beings the initiation phase where the following information must be collected and consolidated:

• Reference people: identify key people for the project;
• Administration and billing: identify reference people for administration and billing
• Change management: identify a process to formally manage change requests
  • Inquire
  • Approval and approvers
  • Document templates
  • Internal tracking
• Communication tools:
  • Project documentation (architecture, infrastructure, ADRs, etc.)
  • Project planning (project artifacts like planning, gantt, activities, etc.)
  • Informal communication channels (teams, chats, email, etc.)
  • Formal communication channels (email, portals, meetings, etc.)
• Project methodology:
  • Waterfall (i.e. requirement => analysis => dev => test => uat => ...)
  • Agile (Scrum, Kanban, etc.)
  • Hybrid (Waterfall planning, agile development)
• Project cerimonies
  • Progress of work meeting / sprint review (weekly, biweekly, etc.)
  • Daily meeting
  • Retrospective, Project control
• Project artifacts:
  • Gantt vs product backlog
  • User story vs requirement management
• Project Metrics
  • Velocity
  • Efficiency
  • Quality
  • Cost
  • Time

The primary goal of a project lead is to reduce uncertainty. The project initiation starts with high uncertainty and must land with low uncertainty about the project execution.

Project Status Report

Project Leads and Project References are asked to provide a Project Status on a monthly basis.

This is a tool to monitor, control, coordinate, share knowledge, and lower risks:

• Issues
• Resolution of issues
• Good and bad practices

• Technical and organizational news can be shared within the circle providing input for continuous improvement.

• Elapseit Tasks are used to trace:

  • Milestone: deliverable recognized by customers, Account, BU Lead, Project Lead and team members
  • Change Request: Fixed Price projects require strict management of Change Requests
  • Incident: a project related event that can compromise customer satisfaction and relationship

Project Logs

Project Leads play a central role in the circle since they convey most of the information of a Business Unit. They follow projects and can return feedback that can be very helpful to drive business unit decisions. A business unit may organize an easy way to share those information and use self-management to address concerns and issues. At the same time, the circle can also link information that may be used to optimize the circle.

Here some examples:

• Exceeding resources of projects to compensate for a lack of resources of another projects
• Interruption of projects due to budget limits
• Key people of a customer's organization moving around or leaving
• Business opportunities like discussion around data-related projects, requests for POCs,etc.

Information relevance is based on urgency / importance:

• Urgency: cannot be delayed
• Importance: cannot be overlooked

Reporting follows this principle:

• Important information must be reported as Holaspirit tensions and planned for the next available tactical.
• Urgent information must be reported by email to BU Lead, Account and any internal stakeholder involved. Call BU Lead and/or Account to accelerate information delivery.

Project Layout

Every project must have a dedicated Sharepoint Folder SHP://BusinessUnit/PROJECTS/<PROJECT_NAME>. The folder layout must be structured as follows:

SHP_BU/PROJECTS/<PROJECT_NAME>/<DATE>/
|- ARCHITECTURE
|- PLANNING
|- DOMAIN_KNOWLEDGE
|- CHANGE_REQUESTS/<ELAPSEIT_CR_ID> #Fixed Price Project Only
   |- scope.pptx 
   |- estimates.xsls

Project Metrics

The Microsoft Form q / BU Project Assessment must be used to compile project-related metrics.

This form collects all the necessary measures to produce:

• Circle Metrics
  • SPACE
  • Average of Velocity [%] (Completed backlog / Planned backlog)
  • Average of Efficiency [%] (Billed hours / Billable hours)

Project lifecycle

The project lifecycle is really dependent on how a customer uses to run a project.
We work with customers adopting scrum, scaled agile frameworks, waterfall and anything in the middle.
Thus, we adapt to customers processes and practices.

Nevertheless, whenever we detect ways to bring values through our agile methodology, we keep proposing activities, practices and improvements.

We monitor the project quality looking into different dimensions: Software Quality and Customer Satisfaction.
The Software Quality provides insights about what we are really doing and how.
The Customer Satisfaction is about a customer feels about our contributions (development, leadership, communication, speed).
They are both important and we care to do our best in the two directions.

For internal projects, we adhere to our Software Development Lifecycle.

We also categorize projects in two types:

• Formal: the customer requires an end to end solution released in production and with full visibility on deliverables. Customer also produces detailed requirements and both functional and technical analysis are required.
• Informal: requirements are leaking, we have to deliver quick win to the customer and the process is clearly iterative.

While working within a project, regardless the project style, we care about the whole lifecycle from requirements to deployment and maintenance:

• Design
• Implementation
• Validation
• Deployment

Design

The Design phase of a project (or iteration) involves Project Leader and Architect, and optionally - but recommended - Developers (at the discretion of the Project Leader). The deliverables at this stage are:

• High-Level Design (HLD)
• Functional Analysis (If the complexity of the problem requires it and we are in the context of a Formal project, this tends to be provided by the customer and validated by the project team)
• Low-Level Design (LLD)

Project Lead and Architect assigned to a project define the HLD document taking into account the following factors:

• Functional requirements of the project
• Possibly pre-existing architecture
• The client's ability to exercise the new architecture (in case Agile Lab is not in charge of the run and maintenance service)
• Deployment Technical Constraints
• Agile Lab Technical Strategy
• Skill of the team that composes the project circle

The HLD is the starting point for discussion and alignment with the development team, and it is an accountability of the Architect. The HLD should go into the following topics (all that apply):

• Logical architecture
• Physical architecture
• Software architecture
• High-level data flow
• Integrations
• Performance analysis

The development team goes into the Low-Level Design, where several aspects are taken into account: logical flow, error handling, interface sketch, logging, patterns, prototyping and all is necessary to comply with customer requirements and project constraints.

For internal projects (or whenever a customer is not ready to manage a backlog or plan), the LLD must be implemented in the form of Issue GitLab to form the project backlog, which will then be iteratively refined throughout the project. Issues can also be integrated with documents, schemas, and everything the development team thinks is necessary to make each development task understandable.

At this stage, it is also necessary to involve the Developer Productivity Ninja who will indicate which software components already developed in the past should be reused or can provide indications on which components could become an asset for the future.

The LLD must then be shared with the Architect and Project Leader and approved by them.

At this point, there are conditions to start the development. HLD/LLD iterations may be shorter or longer depending on the project.

Implementation

This phase may be visible or nor to the customer depending on the kind of commitment established.
Whenever necessary, the software development lifecycle adapts to the customer development practices.
We strive for opportunity to better dev practices and so we feel free to propose improvements to the customer or consider to refactor our development lifecycle if there are good experiences to bring in(see Software Development).

From an operations standpoint we enforce three type of controls along the project lifecycle:

Delivery Control

The circle Engine is the space where Project Leaders and Business Unit Leads can share project status and updates with the COO (Delivery Leader) through tactical meetings.
Project/Business Unit Leads are encouraged to give timely feedbacks anyway.

For projects traced internally, Gitlab must always be updated and provide all the necessary details about the status of a project.

Every three weeks, however, there will be a governance meeting within the circle Engine where any organizational issues within the various projects will be discussed, including resource staffing.

The Project Leader within her/his circle is free to organize the work and coordination methods that she/he considers the most appropriate and for this reason no further details will be defined on this matter, as stated in the handbook regarding the circle's properties.

Formal projects may require the PMO to maintain higher-level project plan and manage the communication flow with the customer.

Technical Control

At the beginning of each project, an "Architect" is assigned to agree on system architecture and technologies that will be used, so that customer expectations and technological consistency will be preserved.

Along with the implementation phase, the Project Leader is responsible for the quality of the code and all the technical detail choices that arise on a daily basis, this is done through a system of code review and feedback. Each member of the development team should be proactive in solving problems and sharing solutions with the Project Leader and Architect as it pertains to them. If the choices to be made represent a change or introduce new aspects to the system from an architectural standpoint, it will be necessary to align the Architect and also produce a new version of HLD.

Each team member must be respectful of the organization and the Project Leader's decisions, helping him or her maintain leadership and taking care of the team's success. If the Project Leader does not have enough technical leadership to make good decisions, they can use the support of the Architect and consult the Software Factory circle. Software Factory cares about best practices and guidelines, it is not in charge of specific developments and cannot decide disruptive changes. If the proposed solution changes the behavior of the system, a comparison with the Architect is therefore required.

This circle Software Factory may require to have in-depth sessions with the project team and/or participate in the code review phases with individuals.

It is very important to distinguish between "system" and "implementation" aspects, software developers can suggest system solutions (as well as others that participate in informal meetings or brainstorming sessions), but these must always be reported and validated by the Architect to be sure to take decisions with the appropriate context and vision.

Financial Control

The costs of Agile Lab projects are kept under control with a budgeting tool: Elapseit. Company staff will need to fill out allocation timesheets directly on this tool at least on a weekly basis, to allow appropriate cost tracking and reporting.

Strategic Control

Project Leads are key people in a project. They are asked to gain context and apply the strategic vision of Agile Lab.

A Project Lead sets all the necessary meetings and project artifacts to keep information, communication, decision-making traced and functioning.

Macro-plans, strategic meetings, partnership with and sponsorship by our customers are activity to nurture and care about.

Periodically, Customer Account and Project Lead should align each other on the following items:

• Actual importance of the customer for Agile Lab
• Prospective importance of the customer for Agile Lab
• Where the project is located in the overall customer strategy
• What topics or projects will be pushed to the customer in the next months
• What aspects or dynamics should be seized by the project leader

People Management

Career Path

The career ladder is complex and requires a certain effort to manage it seriously over many members.

Having a clear pictures of the circle’s members may help a BU Lead to keep up with their progresses.

Also, the BU Leas takes notes about each member and check if it is time to consider any actions for improvement or recognition of maturity.

1o1s

1-o-1s meetings is a safe space for people to grow.

A BU Lead may find it difficult to schedule many ad-hoc meetings periodically.

It may be useful to introduce some practices in the BU circle to make the life easier for everyone.

The BU Lead proposes a fixed schedule where the circle members can participate through a planned schema.

Such a schema is very simple but still requires education to make it work well.

Expect an initial period to let anyone getting the new habit. Thus, it will go easy and well.

If the BU starts growing, the BU Lead can relax the calendar to fit everyone needs we some extra easy rules.

For instance, it is possible to split the fixed schedule between even and odd weeks and run bi-weekly meetings per member.

Do not use 1-o-1s for project alignment. There will be circle tacticals and other occasions to do that. Focus on personal and professional growth of circle’s members and issues that cannot be addressed elsewhere.

The BU Lead wants to take notes about BU members. This should help trace short/long term objectives, personal and professional growth achievements, etc.

Skip Level 1o1s (SL1o1s)

As a BU Lead, it is very useful gathering feedbacks not from the front lines only.

Periodically setup a schedule up with all members of the circle.

This helps a BU Lead keeping in contact with everyone and gaining insights about the BU itself, projects, feedbacks for project leads and references, customers’s info, etc.

This 1-o-1s may require a larger timeframe since you are running those meetings with members you usually talk less.

• The BU Lead plans quarterly 1o1s with a sample of team members within BU projects.

360 review

• See 360 Review

Salary Review

• See Salary Review

Principles

Two main principles to take into account while managing salaries for the members of a Business Unit

• Meritocracy
• Fairness

The career ladder provides the right perspective to assign and review salaries. Other considerations are necessary to include factors that may not be captured by the career ladder. Here some examples:

• Previous professional experiences significant for our business
• Changes in the job market
• Specific working conditions

Salary reviews

At company level, AgileLab provides an annual budget for cost growth. This must be taken into account while reviewing salaries.

As BU Lead wants to optimize the total budget and allocate such a budget along the year.

Reminder: BU leads can review salaries of members behind of two Ladder levels.

See Salary Review for more information.

Coaching

• Coaching is requested on demand or sensed by the BU Lead
• Coaching is reported on [YYYY Agile - Consulting - Coaching] on Elapseit

Customer caring and planning

The BU Lead periodically checks for customer satisfaction and for opportunities to grow.

This is very useful to move the demand plan and provide Accounts (circle Sales) with inputs to sell.

This activity also reduces the risk to surprises. Sampling over time customer needs, we’ll let the BU Lead to know more about news and customer’s internal dynamics.

Also, this is an occasion for the BU Lead to build her/his knowledge about the customer’s organization (that is often complex and unclear)

Bid Management

Participation in the tender is instructed by Successful Bid according to the following accountabilities:

• Tender Officer: Administrative Response.
• BU Lead: technical proposal including, delivery, services, products, BU Leads can involve internal resources to address specific competencies to prepare the best answer for the Bid.
• Account: Financial Proposal.

Technical and economic bid

The format of the technical and economic bid depends on the client and the subject matter. Close cooperation between Tender Officer, BU Lead and Account is always necessary so that the data provided, the form and structure of the content, and the economic bid comply with the specifications of the tender and do not violate any constraints for participation in the tender. In addition, Account and BU Lead must coordinate all necessary bid evaluation activities by service and product partners for the purpose of formulating the best bid.

Tender outcome notification

To facilitate conversations in the management of tenders, we make use of the Utility Internal Sales channel (or channels specifically created for the management of a specific tender). These channels are used to communicate the outcome of important events with respect to the execution of the tender, as well as to organize any KickOff preparations for project activities.

Communication & Knowledge Sharing

Recurring Business Unit Newsletter

The Business Unit sends a quarterly newsletter to share results with the rest of the company.

This is managed by the role Generator.

Thought Leadership

The Business Unit makes a collective effort to expose results and contribute to Agile Lab's thought leadership through articles, and public speaking.

Business Unit Knowledge Sharing

Every Business Unit find occasions for knowledge sharing meeting to discuss about issues and solutions of general interest for our project teams. A Business Unit is responsible to build documentation oriented to the data domain and business cases. It is less technical and more business.

This documentation is necessary for multiple needs:

• Project Onboarding
• Sales and Presales activities
• Knowledge Sharing

Circle Metrics

A Business Unit has to be monitored through different perspectives.

The following metrics are currently used to trace the productivity of the Business Unit:

• Efficiency
• Gross Margin

Software quality metrics and indicators are computed from project metrics to align with Consulting:

• Average of Defects Registered In Backlog
• Average of Code Coverage [%]
• Average of Perceived Technical Debt [Mandays]
• Average of SW
• Average of DE
• Average of DS and are placed in Consulting / metrics / consulting metrics YYYY.